[Bug fortran/30876] Array valued recursive function rejected
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-22 07:41 --- (In reply to comment #5) Then, the following should be invalid and rejected, shouldn't it? recursive function f(i) integer :: f, i f = 0 if (i 0) f = f(i-1) + 1 end function NAG f95: line 4: Recursive invocation of F which has no RESULT clause (gfortran and ifort allow this) recursive function f(i) result(g) integer :: g, i g = 0 if (i 0) g = g(i-1) + 1 end function NAG f95: Inconsistent usage of G ifort: This name has not been declared as an array or a function gfortran: Cannot assign to a named constant -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30876
[Bug fortran/31299] getlog returns blanks when not run from the command prompt
--- Comment #8 from burnus at gcc dot gnu dot org 2007-03-22 07:42 --- Close as Won't Fix -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug fortran/31299] Use getpwuid(geteuid()) instead of getlogin() for GETLOG()
--- Comment #9 from burnus at gcc dot gnu dot org 2007-03-22 09:36 --- Bob Proulx wrote at bugs-coreutils@ Regardless of that I think it would be better if the program calling getlogin() avoided using it since using the utmp file for this accounting is often a source of troublesome errors. The login user is rarely the right answer. Usually the current effective id provided by getpwuid(geteuid()) would be better. I expect that use of getlogin() in the original case that motivated this example is actually a bug by itself. Thus: We should consider using getpwuid(geteuid()) which is also what g95 does, maybe guarded by #ifdef (or maybe not, both are part of IEEE 1003.1-2001/POSIX): #include pwd.h struct passwd *getpwuid(uid_t uid); and #include unistd.h uid_t geteuid(void); (I somehow missed initially the clause getlogin() function shall return a pointer to a string containing the user name associated by the login activity with the *controlling terminal* of the current process.) One should probably also update the manual together with this change?!? -- burnus at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | Summary|getlog returns blanks when |Use getpwuid(geteuid()) |not run from the command|instead of getlogin() for |prompt |GETLOG() http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug c++/31309] g++ 4.2.0 amd64 codegen issue with -O0. 6 byte assignment at end of structure reads/writes past end of structure causing SEGV when that memory is not accessable.
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-22 10:03 --- Confirmed. The program segfaults also with -fno-inline -O[12] and we create very interesting code for XXX::Initialize: _ZN3XXX10InitializeEi: .LFB4: movq(%rdi), %rax movslq %esi,%rsi pushq %rbx .LCFI0: movq(%rax,%rsi,8), %rbx movb$0, 8(%rbx) movb$0, 9(%rbx) call_Z17INIT_6_BYTES_ZEROv movq10(%rbx), %rdx movzbl %al, %esi movzbl %ah, %ecx xorb%dl, %dl orq %rsi, %rdx movq%rax, %rsi movb%cl, %dh movq%rax, %rcx andl$4278190080, %esi andl$16711680, %ecx andq$-16711681, %rdx orq %rcx, %rdx movabsq $-4278190081, %rcx andq%rcx, %rdx movabsq $1095216660480, %rcx orq %rsi, %rdx movq%rax, %rsi andq%rcx, %rsi movabsq $-1095216660481, %rcx andq%rcx, %rdx movabsq $280375465082880, %rcx andq%rcx, %rax orq %rsi, %rdx movabsq $-280375465082881, %rcx andq%rcx, %rdx orq %rax, %rdx movq%rdx, 10(%rbx) popq%rbx ret -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-22 10:03:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug fortran/31310] New: gfortran is missing -fcase-preserve option
using gcc version 4.3.0 20070315 (experimental) The -fcase options are not in gfortran as they were in g77. Specifically -fcase-preserve. This makes it very hard to link to pre-compiled C libraries that have mixed case function names. compile line and error message C:\shagfortran -c sha.f90 -fcase-preserve f951.exe: error: unrecognized command line option -fcase-preserve There is mention of -fcase-lower in the gfortran .pdf manual but it doesn't exist either. The addition of this g77 option to gfortran would be appreciated. Or a workaround / new method for mixed case functions calls from gfortran to C. -- Summary: gfortran is missing -fcase-preserve option Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mralanmorgan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31310
[Bug fortran/31310] gfortran is missing -fcase-preserve option
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-22 13:05 ---
Or a workaround / new method for mixed case functions calls from gfortran
to C.
In the Fortran-Experiments branch exists support for C bindings:
subroutine fortranname bind(C,name='C_Name')
(Planned to be included in GCC/gfortran 4.3 rather soon.)
g77 has a huge number (~20) of case options, cf.
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Fortran-Dialect-Options.html#index-g_t_002dfintrin_002dcase_002dinitcap-option-237
In gfortran's invoke.texi:
For example, with @option{-funderscoring}, and assuming other defaults like
@option{-fcase-lower} and that @code{j()} and @code{max_count()} are
external functions while @code{my_var} and @code{lvar} are local variables,
a statement like
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31310
[Bug ada/31108] [4.2 regression] ACATS C35507M fails
--- Comment #4 from rolf dot ebert dot gcc at gmx dot de 2007-03-22 13:07 --- I rebuilt gcc-4.2.0 RC1 as of 2007-03-16 yesterday on Windows XP/MinGW and could completely run the ACATS tests (no GNAT tests due to missing expect on my Windows). Only the two tests C5507M and C380004 failed. I had to manually kill C974012 after it had already printed its PASSED message. Should I post a separate bug report for C380004? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
[Bug ada/31108] [4.2 regression] ACATS C35507M fails
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-03-22 13:31 --- Should I post a separate bug report for C380004? It's PR ada/31174. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
[Bug fortran/31193] ICE on non-constant character tranfert
--- Comment #3 from patchapp at dberlin dot org 2007-03-22 13:30 --- Subject: Bug number PR31193 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-03/msg01465.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31193
[Bug ada/31108] [4.2 regression] ACATS C35507M fails
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-22 13:31:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
[Bug ada/31174] [4.2 regression] ACATS C380004 fails
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31174
[Bug fortran/31299] I can produce the bug without using nohup
--- Comment #10 from michael dot a dot richmond at nasa dot gov 2007-03-22 13:53 --- Several commenters believe the problem is with nohup rather than gfortran. I can produce the bug without using nohup. I redirect the input to a file: gfortran test_getlog.f90 ./a.out carriage_return Modifying the program to read from the file has no effect. -- michael dot a dot richmond at nasa dot gov changed: What|Removed |Added Summary|Use getpwuid(geteuid()) |I can produce the bug |instead of getlogin() for |without using nohup |GETLOG()| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #24 from jv244 at cam dot ac dot uk 2007-03-22 13:54 --- there is only one file on the web that matches: 'C READ IN HORIZONTAL AND VERTICAL MISALIGNMENT AND TILT' http://mad.home.cern.ch/frs/Source/DA/six.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug fortran/20897] derived type name shall not be same as intrinsic type name
--- Comment #3 from tobi at gcc dot gnu dot org 2007-03-22 14:36 --- I'm testing a very simple fix. -- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-30 19:45:20 |2007-03-22 14:36:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20897
[Bug rtl-optimization/31313] New: consecutive strcmps are not merged
I just ran into some code which did something like
int strcmp(const char *, const char *);
int f (const char *c)
{
return (strcmp (c, aaa) == 0 || strcmp (c, aab) == 0);
}
It would be possible to optimize this into something like (hopefully I get it
right)
int f (const char *c)
{
if (strncmp (c, aa, 2))
return 0;
return ((c[2] == 'a' || c[2] == 'b') !c[3]);
}
Instead, we scan through the whole string twice, as can be seen in the
assembly.
Likewise, more complicated combinations of comparisons could be reduced into an
optimal matching sequence. Putting this into component rtl-optimization,
because the strcmp calls survive all of the tree optimizers unchanged.
--
Summary: consecutive strcmps are not merged
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31313
[Bug fortran/31299] I can produce the bug without using nohup
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-03-22 15:19 --- I say GETLOG should have the same behavior as getlogin which is what this behavior is comming from. Considering the documentation says: On systems where the getlogin(3) function is not implemented, this will return a blank string. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug tree-optimization/31313] consecutive strcmps are not merged
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Component|rtl-optimization|tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31313
[Bug fortran/31310] gfortran is missing -fcase-preserve option
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31310
[Bug c++/31267] #'typename_type' not supported by dump_decl#declaration error
--- Comment #3 from gdr at cs dot tamu dot edu 2007-03-22 15:29 --- Subject: Re: #'typename_type' not supported by dump_decl#declaration error guillaume dot melquiond at ens-lyon dot fr [EMAIL PROTECTED] writes: | I just encountered another instance of a missing typename diagnostic. This time | with a different message, so I add it here for completeness: | | a.cpp:5: error: dependent-name ÂT::#Âtypename_type not supported by | pp_cxx_unqualified_id#::D is parsed as a non-type, but instantiation yields a | type | a.cpp:5: note: say Âtypename T::#Âtypename_type not supported by | pp_cxx_unqualified_id#::D if a type is meant I have a fix for this one. It is not the same issue as your original report. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31267
[Bug fortran/20897] derived type name shall not be same as intrinsic type name
--- Comment #4 from tobi at gcc dot gnu dot org 2007-03-22 15:37 --- Subject: Bug 20897 Author: tobi Date: Thu Mar 22 15:37:25 2007 New Revision: 123129 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123129 Log: PR fortran/20897 fortran/ * decl.c (gfc_match_derived_decl): Reliably reject 'doubleprecision' and 'doublecomplex' as type names. testsuite/ * gfortran.dg/derived_name_1.f90: New. * gfortran.dg/derived_name_2.f: New. Added: trunk/gcc/testsuite/gfortran.dg/derived_name_1.f90 trunk/gcc/testsuite/gfortran.dg/derived_name_2.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20897
[Bug fortran/20897] derived type name shall not be same as intrinsic type name
--- Comment #5 from tobi at gcc dot gnu dot org 2007-03-22 15:39 --- Fixed on the mainline. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20897
[Bug fortran/20897] derived type name shall not be same as intrinsic type name
-- tobi at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20897
[Bug c++/31309] g++ 4.2.0 amd64 codegen issue with -O0. 6 byte assignment at end of structure reads/writes past end of structure causing SEGV when that memory is not accessable.
--- Comment #3 from taavib at ca dot ibm dot com 2007-03-22 15:49 --- Thanks for figuring out how to reproduce this standalone, Peeter! -- taavib at ca dot ibm dot com changed: What|Removed |Added CC||taavib at ca dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug c++/31314] New: Segmentation fault when assign std::string to another std::string when using std::vector and inheritance
Short version:
Assigning an index from a vectorstring to a local string works. Assigning to
a private class member of type string fails with a segmentation fault
apparently caused by a delete[].
I've managed to simplify the test case quite substantially for this bug, but
its still quite convoluted. For this I apologize.
Long version:
Here's a summary of the example: its supposed to be a framework for
implementing model-view-controller type applications in C++. The code is a
foundation for a GTKmm application. We have the Database:: interface which is
implemented by Sqlite::. Each model inherits from the Model:: base class which
is modeled very loosely on the ActiveRecord system in Ruby-on-Rails. The User::
class is a model.
Queries on the database are run through Database::exec() which really is
Sqlite::exec(). The findall() function called in main() is purportedly part of
User:: but actually implemented in Model::.
Now, for the bug.
The example causes a SIGSEGV in User::findall() (ie. Model::findall()). But the
shocker is where it happens: line 130 in the example. We've run Sqlite::exec(),
and gotten a vector of strings. We can also loop over the vector and print each
string.
I have no idea why this bug occurs in this specific code. The only thing
remotely unusual is the inheritance pattern (ie. class User: public ModelUser
{} ), but that's not particularly bizarre either.
--
Summary: Segmentation fault when assign std::string to another
std::string when using std::vector and inheritance
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wmacura at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31314
[Bug c++/31314] Segmentation fault when assign std::string to another std::string when using std::vector and inheritance
--- Comment #1 from wmacura at gmail dot com 2007-03-22 15:58 --- Created an attachment (id=13252) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13252action=view) Testcase (seg at line 130) Build instruction: g++ -g stringtest.cpp -o stringtest -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31314
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #15 from dominiq at lps dot ens dot fr 2007-03-22 16:22 --- Note that the drawback of the optimization replacing sin+cos by cexpi on PPC Darwin has been dissected in PR31249. In comment #16, I proposed a patch. Before applying it, it would be nice to test if the other platforms affected by this bug are also affected by the bad optimization and if the patch does not cause timing regressions on platforms for which the optimization is working (mostly Linux). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug c++/31314] Segmentation fault when assign std::string to another std::string when using std::vector and inheritance
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-22 16:34 --- The problem is with: Row r = r.construct(rawdata.at(i)); You are using r before it is constructored. This is not a bug in GCC but in your code. -- 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=31314
[Bug c++/31314] Segmentation fault when assign std::string to another std::string when using std::vector and inheritance
--- Comment #3 from wmacura at gmail dot com 2007-03-22 16:46 --- Subject: Re: Segmentation fault when assign std::string to another std::string when using std::vector and inheritance :-o Damn. Construct() was a static function for a while and I didn't notice this when I started butchering the code. Thanks. Wiktor On 22 Mar 2007 16:34:01 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-22 16:34 --- The problem is with: Row r = r.construct(rawdata.at(i)); You are using r before it is constructored. This is not a bug in GCC but in your code. -- 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=31314 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31314
[Bug c++/31315] New: internal compiler error on mis-spelled syntax
I tried to compile the following code, but I got internal compiler error: in lookup_member, at cp/search.c:1288 from g++. v.reserve(10); v.push_back(1); v.push_back(2); copy( v.begin() , v.end(). ostream_iteratorint(cout, \n) ); P.S. the correct code should have , after v.end(). not . -- Summary: internal compiler error on mis-spelled syntax Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ahmadyan at gmail dot com GCC build triplet: 3.4.2 release http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31315
[Bug driver/31316] New: driver specifies output file twice when compiling header with -S
[EMAIL PROTECTED]:~/gcc/trunk/gcc/tmp/gcc$ ./xgcc -B. t.h -S -v Reading specs from ./specs Target: i686-pc-linux-gnu Configured with: ../configure --enable-languages=c++ --disable-nls Thread model: posix gcc version 4.3.0 20070322 (experimental) ./cc1 -quiet -v -iprefix /home/ryan/gcc/trunk/gcc/tmp/gcc/../lib/gcc/i686-pc-linux-gnu/4.3.0/ -isystem ./include -isystem ./include-fixed t.h -quiet -dumpbase t.h -mtune=generic -auxbase t -version -o t.s -o /tmp/ccs9IVOl.s --output-pch=t.h.gch cc1: error: output filename specified twice -- Summary: driver specifies output file twice when compiling header with -S Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmansfield at qnx 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=31316
[Bug fortran/31193] ICE on non-constant character tranfert
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-22 18:37 --- Subject: Bug 31193 Author: pault Date: Thu Mar 22 18:37:16 2007 New Revision: 123131 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123131 Log: 2006-03-22 Paul Thomas [EMAIL PROTECTED] PR fortran/31193 * trans-intrinsic.c (gfc_size_in_bytes): Remove function. (gfc_conv_intrinsic_array_transfer): Remove calls to previous. Explicitly extract TREE_TYPEs for source and mold. Use these to calculate length of source and mold, except for characters, where the se string_length is used. For mold, the TREE_TYPE is recalculated using gfc_get_character_type_len so that the result is correctly cast for character literals and substrings. Do not use gfc_typenode_for_spec for the final cast. 2006-03-22 Paul Thomas [EMAIL PROTECTED] PR fortran/31193 * gfortran.dg/transfer_array_intrinsic_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31193
[Bug c++/31317] New: Fatal error when 'make'
# the system type= Linux localhost.localdomain 2.6.20-1.2925.fc6 #1 SMP Sat Mar 10 18:20:58 EST 2007 i686 i686 i386 GNU/Linux # the options given when GCC was configured/built: /home/jmsimo/gcc/gcc-2.95/configure --prefix=/opt/gcc295 --program-suffix=295 --enable-languages=c,c++ --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions # the complete command line that triggers the bug: make # the compiler output (error messages, warnings, etc.): make[1]: *** [libgcc2.a] Error 1 make[1]: se sale del directorio `/home/jmsimo/gcc/build/gcc' make: *** [all-gcc] Error 2 # the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command, or, in the case of a bug report for the GNAT front end, a complete set of source files (see below): [EMAIL PROTECTED] build]$ make -save-temps make: opción inválida -- a # GNU Make 3.81 # Copyright (C) 2006 Free Software Foundation, Inc. # Este es software libre; consulte en el código fuente las condiciones de copia. # NO hay garantía; ni siquiera para MERCANTIBILIDAD o EL CUMPLIMIENTO DE # ALGÚN PROPÓSITO PARTICULAR. # Este programa fue construido para i686-redhat-linux-gnu Modo de empleo: make [opciones] [objetivo] ... Opciones: -b, -m No se tendrá en cuenta por compatibilidad. -B, --always-make Hace incondicionalmente todos los objetivos. -C DIRECTORIO, --directory=DIRECTORIO Se cambia al DIRECTORIO antes de hacer nada. -d Se imprimirán grandes cantidades de información de depurado. --debug[=BANDERAS]Se imprimirán varios tipos de información de depurado. -e, --environment-overrides Las variables ambientales se imponen a las de los makefiles. -f ARCHIVO, --file=ARCHIVO, --makefile=ARCHIVO Lee al ARCHIVO como un makefile. -h, --help Muestra este mensaje y finaliza. -i, --ignore-errors No se toman en cuenta los errores provenientes de las instrucciones. -I DIRECTORIO, --include-dir=DIRECTORIO Busca dentro del DIRECTORIO los makefiles incluidos. -j [N], --jobs[=N] Se permiten N trabajos a la vez; si no se especifica un argumento son infinitos. -k, --keep-goingSigue avanzando aún cuando no se puedan crear algunos objetivos. -l [N], --load-average[=N], --max-load[=N] No inicia con trabajos múltiples a menos que la carga esté por debajo de N. -L, --check-symlink-times Utiliza el último mtime entre los enlaces simbólicos y los objetivos. -n, --just-print, --dry-run, --recon No ejecuta ninguna instrucción; sólo las muestra. -o ARCHIVO, --old-file=ARCHIVO, --assume-old=ARCHIVO Supone que ARCHIVO es muy viejo y no lo reconstruye. -p, --print-data-base Se imprime la base de datos interna de `make'. -q, --question No se ejecutan las instrucciones; el estado de salida indicará si están actualizados. -r, --no-builtin-rules Se deshabilitan las reglas implícitas almacenadas internamente. -R, --no-builtin-variables Se deshabilitan los ajustes a las variables almacenadas internamente. -s, --silent, --quiet No muestra las intrucciones. -S, --no-keep-going, --stop Desactiva la opción -k. -t, --touch Se tocan los objetivos en vez de reconstruirlos. -v, --version Muestra la versión del make y finaliza. -w, --print-directory Muestra el directorio actual. --no-print-directoryDesactiva -w, aún cuando haya sido activado implícitamente. -W ARCHIVO, --what-if=ARCHIVO, --new-file=ARCHIVO, --assume-new=ARCHIVO Supone que ARCHIVO es infinitamente reciente. --warn-undefined-variables Advierte cuando se hace una referencia a una variable no definida. Este programa fue construido para i686-redhat-linux-gnu Informe sobre los errores a bug-make@gnu.org # Base de datos del Make, mostrada en Thu Mar 22 19:57:01 2007 # Variables # entorno DESKTOP_SESSION = default # entorno GTK_RC_FILES = /etc/gtk/gtkrc:/home/jmsimo/.gtkrc-1.2-gnome2 # entorno DESKTOP_STARTUP_ID = # entorno XAUTHORITY = /tmp/.gdmMQTKPT # entorno GDMSESSION = default # entorno XMODIFIERS = @im=none # entorno SHELL = /bin/bash # entorno _ = /usr/bin/make # entorno USERNAME = jmsimo # entorno DBUS_SESSION_BUS_ADDRESS = unix:abstract=/tmp/dbus-6tmNqzM01c,guid=4b3ceaa35c44e1492ecde9004602c275 # entorno GNOME_KEYRING_SOCKET = /tmp/keyring-kFGit0/socket # entorno LESSOPEN = |/usr/bin/lesspipe.sh %s # entorno PATH = /usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/jmsimo/bin # entorno SESSION_MANAGER = local/localhost.localdomain:/tmp/.ICE-unix/2703 # entorno WINDOWID = 56623185 # entorno GDM_XSERVER_LOCATION = local # por defecto .FEATURES :=
[Bug fortran/31318] New: terminate program when un-allocated array is used
For the illegal code integer, allocatable :: ivec(:) print*,shape(ivec)=,shape(ivec) end gcc version 4.3.0 20070315 (experimental) gfortran -W -Wall -pedantic-errors -std=f2003 -fbounds-check -Werror xshape_alloc.f90 gives shape(ivec)= 4298784 It would be nice if a run-time error message about the use of array that has not been allocated were emitted. A fairly common mistake I make is to pass an array that is allocatable in the caller, before having allocated it, to a procedure as an argument which is not allocatable. Within the procedure, applying SIZE or SHAPE will give strange results. -- Summary: terminate program when un-allocated array is used Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31318
[Bug other/31317] Fatal error when 'make'
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-22 19:40 --- 2.95 is very very old, over 7 years old. Plus only the last three lines of a build failure does not show the problem is. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|c++ |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31317
[Bug c/31319] New: Make big alignment for structs/arrays configurable
Hi from busybox project. We are concerned about gcc sometimes aligning structs and arrays to 256 bits on i386. We would like to be able to disable it. The proposal is to implement new x86-specific -m option, -mbigdata_align=N. N specifies how big the struct/array should be in order to be strongly aligned. Run-tested patch against 4.1.2 is attached. -- Summary: Make big alignment for structs/arrays configurable Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vda dot linux at googlemail dot com GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31319
[Bug c/31319] Make big alignment for structs/arrays configurable
--- Comment #1 from vda dot linux at googlemail dot com 2007-03-22 20:07 --- Patch is available here: http://busybox.net/~vda/mbigdata_align.diff I cannot attach patch to this bugzilla entry because I get this: Internal Error GCC Bugzilla has suffered an internal error. Please save this page and send it to [EMAIL PROTECTED] with details of what you were doing at the time this message appeared. URL: http://gcc.gnu.org/bugzilla/attachment.cgi undef error - Undefined subroutine Fh::slice at data/template/template/en/default/global/hidden-fields.html.tmpl line 58 I already saw this error page ~1 year ago, IIRC. Pity it didn't get more understandable over this time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31319
[Bug other/31282] SegV on AIX 5.3 due to uninit'ed static object when using -pthread
--- Comment #5 from tom dot culliton at oracle dot com 2007-03-22 20:15 --- That does indeed appear to have been the problem. Even though the system claims that APAR was already applied, the header file was still missing the typedef keyword. I suspect something silly like the compiler being reinstalled after the patch was applied the first time. Many thanks! BTW - This also explains a number of other issues I've seen people report with duplicate symbols for 'thread_creds_t', but this is the only item that search turned up in the bug DB that mentions APAR IY90737. -- tom dot culliton at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31282
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #25 from jvdelisle at gcc dot gnu dot org 2007-03-22 20:38 --- Created an attachment (id=13255) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13255action=view) Untested patch to fix regression on sixtrack This patch reverts portions of the original patch and keeps a minimal set of changes to see if this clears the regression. The patch is against current trunk. If you could please test, I would appreciate. Regression tested on x86-64-Gnu/Linux I do not have a testcase here yet. If this fails, then I will try a further reduction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug target/31319] Make big alignment for structs/arrays configurable
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-22 21:14 --- I think this has already been fixed for -Os in 4.2.0 or 4.3.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31319
[Bug fortran/27589] Add compiler flag to check for uninitalized values at runtime
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-22 22:20 --- There are actually two run-time tests possible: a) Check only local variables (What to do about actual arguments to intent(in) dummy arguments? In the most cases this is wrong, however foo(read_argument=.false.,arg=uninitialized) is possible. Better don't check - or only optionally.) This seems to be done by ifort's -check uninit. b) Checking all calls, i.e. by passing additional information. This is done by NAG f95's -C=undefined. This is more comprehensive, but makes procedures compiled -C=undefined incompatible to those compiled without. Ideally, gfortran should offer both options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27589
[Bug fortran/29616] Run-time check using nullified pointers and deallocated variables
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-22 22:30 --- Besides pointers, the same is also true for deallocated variables, only that the unknown state does not exist. (Idea taken from 31318) I think there are essentially two problems possible with pointers: (a) Uninitialized pointer (i.e. neither NULL nor associated) (b) Using an unassociated pointer I think checking (a) is not easily doable as one would need to pass this status (has been initialized? yes/no) on to subroutines. (a) should be possible if one restricts oneself to restricts oneself to local variables. If they are passed as actual argument to non-pointer (or non-allocatable) dummies, this is also an error. For allocatable variables the checking is always possible. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|Run-time check using|Run-time check using |nullified pointers |nullified pointers and ||deallocated variables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29616
[Bug fortran/31318] Run-time check for using deallocated variables
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-22 22:32 --- This is related to 29616 (same for nullified pointers). As the test is essentially the same, I added a comment there and close this PR as duplicate. Thanks for the idea though it will likely take a while until it will be implemented. *** This bug has been marked as a duplicate of 29616 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Keywords||diagnostic Resolution||DUPLICATE Summary|terminate program when un- |Run-time check for using |allocated array is used |deallocated variables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31318
[Bug fortran/29616] Run-time check using nullified pointers and deallocated variables
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-22 22:32 --- *** Bug 31318 has been marked as a duplicate of this bug. *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29616
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #30 from manu at gcc dot gnu dot org 2007-03-22 22:36 ---
There is yet another strange behaviour of the current patch. For the testcase
in gcc.dg/array-2.c:
struct g g1 = { { 0, { } } };
struct g g2 = { { 0, { 1 } } }; /* { dg-error (nested context)|(near
initialization) nested } */
struct h { int x[0]; int y; };
struct h h1 = { { 0 }, 1 }; /* { dg-error (excess elements)|(near
initialization) before end } */
The output is:
gcc.dg/array-2.c:10: error: initialization of flexible array member in a nested
context
gcc.dg/array-2.c:10: error: (near initialization for 'g2.f.x')
gcc.dg/array-2.c:13: warning: excess elements in array initializer
gcc.dg/array-2.c:13: warning: (near initialization for 'h1.x')
And the test fails as follows:
PASS: gcc.dg/array-2.c nested (test for errors, line 10)
PASS: gcc.dg/array-2.c before end (test for errors, line 13)
FAIL: gcc.dg/array-2.c (test for excess errors)
Excess errors:
/home/manuel/src/trunk/gcc/testsuite/gcc.dg/array-2.c:13: warning: excess
elements in array initializer
It seems that the second dg-error matched the wrong line. Perhaps it is getting
confused by the alternatives. No idea.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug fortran/31262] -fno-range-check with large integer values triggers ICE
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-22 22:52 --- Subject: Bug 31262 Author: fxcoudert Date: Thu Mar 22 22:51:50 2007 New Revision: 123136 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123136 Log: PR fortran/31262 * trans-const.c (gfc_conv_mpz_to_tree): Allow integer constants larger than twice the width of a HOST_WIDE_INT. * gfortran.dg/no_range_check_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/no_range_check_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31262
[Bug fortran/31262] -fno-range-check with large integer values triggers ICE
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-22 22:52 --- Fixed on mainline, closing. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31262
[Bug other/23572] No warning for assigning a value to a 'float' variable that overflows with option -Wextra
--- Comment #11 from manu at gcc dot gnu dot org 2007-03-22 23:04 --- Subject: Bug 23572 Author: manu Date: Thu Mar 22 23:04:24 2007 New Revision: 123137 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123137 Log: 2007-03-22 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR other/23572 * c-lex.c (interpret_float): On overflow, emit pedantic warning if infinities not supported, otherwise emit warning if -Woverflow. On underflow, emit warning if -Woverflow. * real.c (real_from_string): Return -1 if underflow, +1 if overflow and 0 otherwise. * real.h (real_from_string): Update declaration testsuite/ * gcc.dg/float-range-4.c: New. * gcc.dg/float-range-1.c: Update. Test for a warning. * gcc.dg/float-range-3.c: New. * gcc.dg/float-range-5.c: New. Added: trunk/gcc/testsuite/gcc.dg/float-range-3.c trunk/gcc/testsuite/gcc.dg/float-range-4.c trunk/gcc/testsuite/gcc.dg/float-range-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-lex.c trunk/gcc/real.c trunk/gcc/real.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/float-range-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23572
[Bug other/23572] No warning for assigning a value to a 'float' variable that overflows with option -Wextra
--- Comment #12 from manu at gcc dot gnu dot org 2007-03-22 23:12 --- Fixed for GCC 4.3 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23572
[Bug c++/31074] [4.1/4.2/4.3 Regression] Reference casting involving multiple inheritance produces bad pointer
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31074
[Bug c/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
[Bug middle-end/31150] [4.1/4.2/4.3 Regression] Not promoting an whole array to be static const
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31150
[Bug middle-end/29609] [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609
[Bug fortran/31320] New: Illegal read with gfortran.dg/alloc_comp_assign_2.f90 and *_3.f90
gfortran -g gfortran.dg/alloc_comp_assign_2.f90 valgrind ./a.out ==30049== Invalid read of size 1 ==30049==at 0x4C24854: memcpy (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==30049==by 0x401682: MAIN__ (in /projects/tob/gcc/gcc/testsuite/gfortran.dg/a.out) ==30049==by 0x405FAB: main (fmain.c:22) ==30049== Address 0x404D64B is 3 bytes after a block of size 16 alloc'd ==30049==at 0x4C22C56: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==30049==by 0x4E3DD78: _gfortrani_get_mem (memory.c:53) ==30049==by 0x400A5C: MAIN__ (in /projects/tob/gcc/gcc/testsuite/gfortran.dg/a.out) ==30049==by 0x405FAB: main (fmain.c:22) I checked the example itself with g95 and NAG f95 and both fail at the second, third and fourth call abort() whereas ifort has a segv. Is this example (PR 20541) really valid? A check with NAG f95, g95 and ifort with valgrind shows no problem for NAG f95, and invalid reads for g95 and ifort. For alloc_comp_assign_3.f90: Compiles with g95, ifort and NAG f95 and gives no call abort(), however, gfortran has: ==30454== Invalid read of size 1 ==30454==at 0x4C24854: memcpy (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==30454==by 0x401223: MAIN__ (alloc_comp_assign_3.f90:22) ==30454==by 0x40444B: main (fmain.c:22) ==30454== Address 0x404D64B is 3 bytes after a block of size 16 alloc'd ==30454==at 0x4C22C56: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==30454==by 0x4E3DD78: _gfortrani_get_mem (memory.c:53) ==30454==by 0x400A5C: MAIN__ (alloc_comp_assign_3.f90:19) ==30454==by 0x40444B: main (fmain.c:22) For alloc_comp_initializer_1.f90 the same. -- Summary: Illegal read with gfortran.dg/alloc_comp_assign_2.f90 and *_3.f90 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: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31320
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug c++/31260] [4.1/4.2/4.3 Regression] ICE: segmentation fault with template code
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31260
[Bug c++/31273] [4.2/4.3 Regression] Erroneous bitfield conversions to boolean values
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-03-22 23:22 --- Jim -- Your patch is correct. If you would care to test it, it's preapproved for 4.2/4.3. Otherwise, I will take care of it before the 4.2.0 release, as it's certainly my fault. Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31273
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-03-22 23:34 --- Jason -- This appears to be fallout from your patch for PR c++/28407 and/or c++/28409. Do you have time to take a look? Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug c/31321] New: gcc fails to compile simple long double initializers
gcc-4.3-20070316 and gcc-4.2-20070307 both fail to compile this one-line file on Mac OS X 10.4.9 (up to current Apple patch levels): % cat foo.c static const long double X = (27.0L) / (35.0L); % gcc-4.3-20070316 -c foo.c foo.c:1: error: initializer element is not constant If the divisor is changed to 32.0L, it compiles, as does any similar statement where the right-hand side can be evaluated exactly. The compilers were built like this: nice time env LDFLAGS=-L/usr/local/lib \ ../gcc-4.3-20070316/configure \ --enable-decimal-float \ --enable-languages=c,c++ \ --with-gmp=/usr/local \ --with-mpfr=/usr/local nice time make bootstrap Similar code with float and double initializers compiles without problems. -- Summary: gcc fails to compile simple long double initializers Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: beebe at math dot utah dot edu GCC build triplet: powerpc-apple-darwin8.9.0 GCC host triplet: powerpc-apple-darwin8.9.0 GCC target triplet: powerpc-apple-darwin8.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31321
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #28 from craig dot lawson at centrify dot com 2007-03-22 23:44
---
For HP-UX, SunOS, and Irix:
#if !defined(_POSIX_C_SOURCE)
# define _POSIX_C_SOURCE 199506L
#elif _POSIX_C_SOURCE199506L
# error Conflict
#endif
(why would anyone compile C++ with POSIX 1995.06?)
For AIX, either:
#define _THREAD_SAFE
or
#define _THREAD_SAFE_ERRNO
Details:
HP-UX 11.00, 11.11, 11.22, 11.23:
errno.h:
#ifdef _REENTRANT
# ifdef _PROTOTYPES
extern int *__errno(void);
# else
extern int *__errno();
# endif
...
However, errno.h includes sys/stdsyms.h which contains:
/* _REENTRANT selects Posix 1c threads unless draft4 selected.
* This usage is obsolescent, -D_POSIX_C_SOURCE=199506 is preferred */
...
#if (_POSIX_C_SOURCE = 199506) !defined(_REENTRANT)
# define _REENTRANT
#endif /* _POSIX_C_SOURCE = 199506 !_REENTRANT */
It appears _POSIX_C_SOURCE=199506 is the desired symbol and value, but
there will be a conflict if intentionally set to something lower (higher
is OK).
Confirm using test program:
#include cerrno
int main() {
return errno;
}
Confirmed: -D_POSIX_C_SOURCE=199506 works.
SunOS 2.6, 7, 5.8, 5.9, 5.10:
errno.h:
#if (defined(_REENTRANT) || defined(_TS_ERRNO) || \
_POSIX_C_SOURCE - 0 = 199506L) !(defined(lint) || defined(__lint))
Confirmed: -D_POSIX_C_SOURCE=199506 works.
AIX 4.3.3, 5.1:
errno.h:
#include standards.h
#ifdef _ANSI_C_SOURCE
# if defined(_THREAD_SAFE) || defined(_THREAD_SAFE_ERRNO)
# define errno (*_Errno())
standards.h:
defines _ANSI_C_SOURCE unless overridden by some other model.
Confirmed: -D_THREAD_SAFE works.
Confirmed: -D_THREAD_SAFE_ERRNO works.
AIX 5.2:
errno.h: similar to 4.3.3
standards.h:
#if defined(_UNIX03)
# define _THREAD_SAFE
...
#if _XOPEN_SOURCE==600
# define _THREAD_SAFE
...
Due to statement ordering in this file, if _POSIX_C_SOURCE==200112L before
including this file, then _THREAD_SAFE will be set. Otherwise, this file
sets _POSIX_C_SOURCE==200112L and does not set _THREAD_SAFE.
Confirmed: -D_THREAD_SAFE works.
Confirmed: -D_THREAD_SAFE_ERRNO works.
Confirmed: -D_UNIX03 works. Size effect: sets _POSIX_C_SOURCE==200112L
Irix 6.5:
errno.h:
#if defined(_SGI_MP_SOURCE) || (_POSIX_C_SOURCE = 199506L) \
|| (_XOPEN_SOURCE+0 = 500)
extern int *__oserror(void);
...
Confirmed: -D_POSIX_C_SOURCE=199506 works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug c/31321] gcc fails to compile simple long double initializers
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-22 23:49 --- *** This bug has been marked as a duplicate of 26374 *** -- 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=31321
[Bug middle-end/26374] Compile failure on long double
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-03-22 23:49 --- *** Bug 31321 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||beebe at math dot utah dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374
[Bug middle-end/31322] New: ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0).
--enable-languages=c,c++,objc,fortran,ada Thread model: posix gcc version 4.3.0 20070322 (experimental) -bash-2.05b$ cat LAST_UPDATED Wed Mar 21 21:02:45 EDT 2007 Thu Mar 22 01:02:45 UTC 2007 (revision 123123M) Looking at the assembly output for debug_list, I see the following in the EH data: .word P%__gxx_personality_v0 There's no .IMPORT directive for __gxx_personality_v0, so the symbol type defaults to DATA which is wrong. If I was to guess, I suspect that the change that introduced this problem was: 2007-03-19 Mark Mitchell [EMAIL PROTECTED] * except.c (output_function_exception_table): Do not reference the EH personality routine for functions that do not require an exception table. -- Summary: ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0). Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31322
[Bug middle-end/31322] [4.3 Regression] ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0).
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|ld: Invalid symbol type for |[4.3 Regression] ld: Invalid |plabel (.libs/debug_list.o, |symbol type for plabel |__gxx_personality_v0). |(.libs/debug_list.o, ||__gxx_personality_v0). Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31322
[Bug libgcj/31228] Race condition between setting close-on-exec and Runtime.exec()
--- Comment #2 from daney at gcc dot gnu dot org 2007-03-23 00:06 --- Subject: Bug 31228 Author: daney Date: Fri Mar 23 00:06:41 2007 New Revision: 123138 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123138 Log: PR libgcj/31228 * configure.ac: Add checks for getrlimit and sys/resource.h. * include/posix.h (_Jv_platform_close_on_exec): Remove. * include/config.h.in: Regenerate. * configure: Regenerate. * gnu/java/nio/channels/natFileChannelPosix.cc (open): Remove call to _Jv_platform_close_on_exec; * gnu/java/net/natPlainSocketImplPosix.cc (create): Likewise. (accept): Likewise. * gnu/java/net/natPlainDatagramSocketImplPosix.cc (create):Likewise. * java/lang/natPosixProcess.cc: Include sys/resource.h. (nativeSpawn): Close all file descriptors. Don't set FD_CLOEXEC on pipes. Modified: trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac trunk/libjava/gnu/java/net/natPlainDatagramSocketImplPosix.cc trunk/libjava/gnu/java/net/natPlainSocketImplPosix.cc trunk/libjava/gnu/java/nio/channels/natFileChannelPosix.cc trunk/libjava/include/config.h.in trunk/libjava/include/posix.h trunk/libjava/java/lang/natPosixProcess.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31228
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #26 from jvdelisle at gcc dot gnu dot org 2007-03-23 00:13 --- Subject: Bug 31052 Author: jvdelisle Date: Fri Mar 23 00:13:19 2007 New Revision: 123139 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123139 Log: 2007-03-22 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/31052 * file_pos.c: Update Copyright year. * io/open.c (test_endfile): Restore test_endfile to fix SPEC regression. Update Copyright year. * io/io.h: Same. * io/unix.c (is_special): Add missing type for this function. Update Copyright year. * io/transfer.c (next_record_r): Restore test_endfile. (st_read): Fix whitespace. Update Copyright year Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/io.h trunk/libgfortran/io/open.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unix.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug libgcj/31228] Race condition between setting close-on-exec and Runtime.exec()
--- Comment #3 from daney at gcc dot gnu dot org 2007-03-23 00:17 --- The committed patch fixes the race. Too bad it had to come to this. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31228
[Bug libgcj/31228] Race condition between setting close-on-exec and Runtime.exec()
-- daney at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31228
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #29 from pcarlini at suse dot de 2007-03-23 00:29 --- Thanks a lot Craig. Touching _POSIX_C_SOURCE makes me a little nervous, in particular if that ends up changing _REENTRANT, as happens on HP-UX. I'd like to ask Dave opinion about it, whether to his best knowledge there is a safe, minimal way to have a thread-safe errno on HP-UX. Otherwise, probably for now we have to be contect to fix only SunOS and AIX (with _THREAD_SAFE_ERRNO), all in all the most important targets these days besides Linux and Darwin. -- pcarlini at suse dot de changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
Re: Bug in g++ 4.1.2 when using inline function definied in cpp file but declared in h file
We don't track bugs reported via email. If you want to make sure you get an answer, use the bugzilla database instead. This doesn't seem to be a gcc bug though. In C++, the inline keyword is similar to what static inline means in GNU C, i.e. only emit the function if it is used. Since there is no use of the function in a.cpp, gcc does not emit it. You can see this if you compile a.cpp with -S and look at the assembler output. You can fix this by deleting the use of the inline keyword. Or you can fix it by putting the inline function definition into the a.h file instead of the a.cpp file. This way it will be visible in main.cpp when we call it, and then gcc will emit it. Or you can fix it by using pragma implementation and pragma interface as you discovered. I'm not a C++ expert. There may also be other ways to fix this. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
[Bug c++/30897] [4.1/4.2/4.3 regression] ICE with default argument in template template parameter
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-03-23 00:50
---
This code in lookup_template_class:
- /* Consider an example where a template template parameter declared as
-
- template class T, class U = std::allocatorT class TT
-
-The template parameter level of T and U are one level larger than
-of TT. To proper process the default argument of U, say when an
-instantiation `TTint' is seen, we need to build the full
-arguments containing {int} as the innermost level. Outer levels,
-available when not appearing as default template argument, can be
-obtained from `current_template_args ()'.
-
-Suppose that TT is later substituted with std::vector. The above
-instantiation is `TTint, std::allocatorT ' with TT at
-level 1, and T at level 2, while the template arguments at level 1
-becomes {std::vector} and the inner level 2 is {int}. */
-
- if (current_template_parms)
- arglist = add_to_template_args (current_template_args (), arglist);
is simply bogus; the current template arguments have nothing to do with the
situation. It is this code which causes the crash.
I believe that the correct change is to remove that code and to make template
parameters for template template parameters restart at level 1. So, in:
template template typename T class A
class B {};
both T and A have level 1. (Right now, T has level 2.)
T should have level 1 because, when instantiating A, that's what make sense.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30897
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-23
00:56 ---
Subject: Re: c++locale.o thread-unsafe in libstdc++
--- Comment #29 from pcarlini at suse dot de 2007-03-23 00:29 ---
Thanks a lot Craig. Touching _POSIX_C_SOURCE makes me a little nervous, in
particular if that ends up changing _REENTRANT, as happens on HP-UX. I'd like
to ask Dave opinion about it, whether to his best knowledge there is a safe,
minimal way to have a thread-safe errno on HP-UX. Otherwise, probably for now
we have to be contect to fix only SunOS and AIX (with _THREAD_SAFE_ERRNO), all
in all the most important targets these days besides Linux and Darwin.
This is how _POSIX_C_SOURCE affects _REENTRANT on 11.11:
# if (_POSIX_C_SOURCE = 199506) !defined(_REENTRANT)
# define _REENTRANT
# endif /* _POSIX_C_SOURCE = 199506 !_REENTRANT */
In sys/errno.h:
# if defined(_REENTRANT) !defined(_PTHREADS_DRAFT4)
/* Get errno definition by including errno.h not sys/errno.h */
# else /* ! _REENTRANT || _PTHREADS_DRAFT4 */
extern int errno;
# endif /* ! _REENTRANT || _PTHREADS_DRAFT4 */
In errno.h, errno is defined as follows when _REENTRANT is defined:
# ifdef __cplusplus
extern C {
# endif /* __cplusplus */
#ifdef _PROTOTYPES
extern int *__errno(void);
#else
extern int *__errno();
#endif
#define errno (*__errno())
...
Don't see a thread safe implementation in HP-UX 10. I'd be hesitant
about using __errno directly.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug c++/30863] [4.1/4.2/4.3 Regression] Unsigned templatized struct treated as unsigned int
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30863
Re: IEEE Math is not working on Alpha Rawhide
[EMAIL PROTECTED] wrote: checking if IEEE math works with the -mieee switch... not isnan(NaN) ... no Check config.log to see what went wrong ... The -mieee option should have worked. You will need to look at the config.log file to see what went wrong. How can I make gcc support IEEE- math on my system? It seems to be a bug, because on Kernel 2.4 I was able to compile the tool. If this worked on a different kernel with the same compiler version, then that indicates a kernel bug. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
[Bug c++/31300] undetected class name clash
--- Comment #7 from bangerth at dealii dot org 2007-03-23 02:13 --- (In reply to comment #4) I agree , sure it is invalid ,(no mine at the root) but a diagnostic would be nice It is very hard for a compiler to detect this because it only sees that there is a class 'T'. The compiler would need to know whether the declaration came from a header file that both .cc files include or was truly meant to be a local class. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31300
[Bug c++/31273] [4.2/4.3 Regression] Erroneous bitfield conversions to boolean values
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-03-23 02:16 --- Jim -- I'm going to test your patch, and handle getting it checked in. Thank you for your investigation. -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31273
[Bug c++/31315] internal compiler error on mis-spelled syntax
--- Comment #1 from bangerth at dealii dot org 2007-03-23 02:28 --- You need to post a complete testcase, including all include files etc. I can't reproduce the problem with the snippet you posted. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31315
[Bug other/31317] Fatal error when 'make'
--- Comment #2 from bangerth at dealii dot org 2007-03-23 02:29 --- You need to use 'make bootstrap' instead of just 'make'. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31317
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
--- Comment #4 from bangerth at dealii dot org 2007-03-23 02:37 --- Without wanting to be a distractor, but can variables of a type that was declared in an anonymous namespace really have external linkage? Think of the type being declared in a header file and one .cc file has the variable declaration/definition and another one an extern declaration for that variable. Do they refer to the same variable? I don't think so -- they have the same name, but distinct types, so we have an ODR violation. IMHO, variables with a type that comes from an anonymous namespace can but have internal linkage. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
--- Comment #5 from mark at codesourcery dot com 2007-03-23 02:44 --- Subject: Re: [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument bangerth at dealii dot org wrote: --- Comment #4 from bangerth at dealii dot org 2007-03-23 02:37 --- Without wanting to be a distractor, but can variables of a type that was declared in an anonymous namespace really have external linkage? That's not the case here; the class is in the global namespace. Only the variable is in the anonymous namespace, and entities in anonymous namespaces do have external linkage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
--- Comment #6 from bangerth at dealii dot org 2007-03-23 03:03 --- (In reply to comment #5) That's not the case here; the class is in the global namespace. Oh, bummer, of course... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug c++/31267] #'typename_type' not supported by dump_decl#declaration error
--- Comment #4 from gdr at gcc dot gnu dot org 2007-03-23 03:04 --- ttp://gcc.gnu.org/ml/gcc-patches/2007-03/msg01513.html -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31267
[Bug c++/30982] Junk in diagnostic message
-- gdr at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |gdr at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-09 04:43:13 |2007-03-23 03:06:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30982
[Bug c++/30982] Junk in diagnostic message
--- Comment #3 from gdr at gcc dot gnu dot org 2007-03-23 03:07 --- http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01513.html -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30982
[Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
--- Comment #6 from jsm28 at gcc dot gnu dot org 2007-03-23 03:45 --- Analysis: http://gcc.gnu.org/ml/gcc/2007-03/msg00867.html -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
[Bug c++/31273] [4.2/4.3 Regression] Erroneous bitfield conversions to boolean values
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-03-23 04:26 --- Subject: Bug 31273 Author: mmitchel Date: Fri Mar 23 04:26:13 2007 New Revision: 123149 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123149 Log: Mark Mitchell [EMAIL PROTECTED] PR c++/31273 * call.c (standard_conversion): Use type_decays_to. Keep FCODE consistent with FROM. PR c++/31273 * g++.dg/expr/bitfield7.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/expr/bitfield7.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/call.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31273
[Bug c++/31273] [4.2/4.3 Regression] Erroneous bitfield conversions to boolean values
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-03-23 04:31 --- Fixed in 4.2.0. --- Comment #8 from mmitchel at gcc dot gnu dot org 2007-03-23 04:31 --- Subject: Bug 31273 Author: mmitchel Date: Fri Mar 23 04:31:21 2007 New Revision: 123150 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123150 Log: Mark Mitchell [EMAIL PROTECTED] PR c++/31273 * call.c (standard_conversion): Use type_decays_to. Keep FCODE consistent with FROM. PR c++/31273 * g++.dg/expr/bitfield7.C: New test. Added: trunk/gcc/testsuite/g++.dg/expr/bitfield7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31273
[Bug c++/31273] [4.2/4.3 Regression] Erroneous bitfield conversions to boolean values
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-03-23 04:31 --- Fixed in 4.2.0. --- Comment #8 from mmitchel at gcc dot gnu dot org 2007-03-23 04:31 --- Subject: Bug 31273 Author: mmitchel Date: Fri Mar 23 04:31:21 2007 New Revision: 123150 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123150 Log: Mark Mitchell [EMAIL PROTECTED] PR c++/31273 * call.c (standard_conversion): Use type_decays_to. Keep FCODE consistent with FROM. PR c++/31273 * g++.dg/expr/bitfield7.C: New test. Added: trunk/gcc/testsuite/g++.dg/expr/bitfield7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31273
[Bug c++/30863] [4.1/4.2/4.3 Regression] Unsigned templatized struct treated as unsigned int
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-03-23 04:36 --- Subject: Bug 30863 Author: mmitchel Date: Fri Mar 23 04:36:33 2007 New Revision: 123151 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123151 Log: PR c++/30863 * parser.c (cp_parser_parse_and_diagnose_invalid_type_name): Do not consume tokens when failing. PR c++/30863 * g++.dg/template/error24.C: New test. * g++.dg/parse/tmpl-outside1.C: Tweak error markers. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/error24.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/parser.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/g++.dg/parse/tmpl-outside1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30863
[Bug c++/30863] [4.1/4.2/4.3 Regression] Unsigned templatized struct treated as unsigned int
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-03-23 04:37 --- Subject: Bug 30863 Author: mmitchel Date: Fri Mar 23 04:37:40 2007 New Revision: 123152 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123152 Log: PR c++/30863 * parser.c (cp_parser_parse_and_diagnose_invalid_type_name): Do not consume tokens when failing. PR c++/30863 * g++.dg/template/error24.C: New test. * g++.dg/parse/tmpl-outside1.C: Tweak error markers. Added: trunk/gcc/testsuite/g++.dg/template/error24.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/tmpl-outside1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30863
[Bug c++/30863] [4.1 Regression] Unsigned templatized struct treated as unsigned int
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-03-23 04:37 --- Fixed in 4.2.0, 4.3.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 Regression]|[4.1 Regression] Unsigned |Unsigned templatized struct |templatized struct treated |treated as unsigned int |as unsigned int http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30863
[Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
--- Comment #7 from spark at gcc dot gnu dot org 2007-03-23 05:00 --- Follow up on Joseph's analysis: The problematic STRIP_SIGN_NOPS() call is from fold_unary() which is called from try_combine_conversion() in tree-ssa-pre.c. STRIP_SIGN_NOPS() is called with the expression: nop_expr 0x866f220 type integer_type 0xf7e30678 public unsigned QI size integer_cst 0xf7d781e0 constant invariant 8 unit size integer_cst 0xf7d781f8 constant invariant 1 align 8 symtab 0 alias set -1 precision 4 min integer_cst 0xf7e32618 0 max integer_cst 0xf7e32630 15 arg 0 integer_cst 0xf7e327b0 type integer_type 0xf7e306d4 constant invariant 31 and it stripes away the conversion, leaving only integer constant 31. This is clearly wrong as it removes the downconversion of precision. Following patch (against 4.2 branch) seems to fix the problem: Index: tree.h === --- tree.h (revision 123088) +++ tree.h (working copy) @@ -912,7 +912,9 @@ extern void omp_clause_range_check_faile (TYPE_MODE (TREE_TYPE (EXP))\ == TYPE_MODE (TREE_TYPE (TREE_OPERAND (EXP, 0 \ (TYPE_UNSIGNED (TREE_TYPE (EXP))\ -== TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (EXP, 0) \ +== TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (EXP, 0\ + (TYPE_PRECISION (TREE_TYPE (EXP)) \ += TYPE_PRECISION (TREE_TYPE (TREE_OPERAND (EXP, 0)\ (EXP) = TREE_OPERAND (EXP, 0) /* Like STRIP_NOPS, but don't alter the TREE_TYPE either. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
[Bug c++/31323] New: typename A::B * p; in template definition, with curiously recurring template inheritance
The following code doesnt compile with gcc, dmc, icc. Im not sure if its
correct code, but it looks like it is.
#include iostream
using std::cout;
using std::endl;
template class T
class Base
{
protected:
typename T::privIC * priv;
public:
virtual int f1() =0;
virtual int f2() =0;
};
class A : public BaseA
{
public:
class privIC
{
int i;
};
int f1();
int f2();
};
int A::f1()
{
return 0;
}
int A::f2()
{
return 0;
}
int main()
{
A a;
cout a.f2() endl;
}
--
Summary: typename A::B * p; in template definition, with
curiously recurring template inheritance
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mesti_mudam at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31323
[Bug c++/31323] typename A::B * p; in template definition, with curiously recurring template inheritance
--- Comment #1 from bangerth at dealii dot org 2007-03-23 06:26 ---
Or smaller like this:
--
template class T struct Base {
typename T::X X;
};
struct A : BaseA
{
typedef int X;
};
--
sunCC also rejects it. I tend to believe that the code is invalid because
at the time where we instantiate BaseA (in the base class list of A), A
is not complete and so the inner typedef is not available yet.
What makes you think that the code should compile?
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31323
[Bug c++/31323] typename A::B * p; in template definition, with curiously recurring template inheritance
--- Comment #2 from mesti_mudam at yahoo dot com 2007-03-23 06:42 --- well, priv is a pointer.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31323
