[Bug driver/30460] [4.0/4.1/4.2/4.3 Regression] asm_debug is not initialized in gcc.c when using a "default" specs file
--- Comment #6 from rschiele at gmail dot com 2007-01-14 08:03 --- Agreed, but why shouldn't we change the special handling of the default specs file as suggested in comment #4? I can't see why we should enforce people to specify _full_ information in the default specs file if they only want to change _one_ thing from the compiled-in values. Is there any reason? As far as I can see my suggestion in comment #4 would solve this issue and make usage of a default specs file more convenient. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30460
[Bug fortran/30452] Strange syntax error with high-value character
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-01-14 11:01 --- Subject: Bug 30452 Author: tkoenig Date: Sun Jan 14 11:01:20 2007 New Revision: 120768 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120768 Log: 2007-01-14 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/30452 * scanner.c(next_char): Cast next character to unsigned to avoid confusion with error return codes. 2007-01-14 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/30452 * gfortran.dg/string_0xfe_0xff_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/string_0xfe_0xff_1.f90 Modified: trunk/gcc/fortran/scanner.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30452
[Bug fortran/25020] NAG extension: module F90_UNIX providing access to UNIX functions (abort ...)
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-30 12:18:39 |2007-01-14 11:02:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25020
[Bug fortran/24783] [4.1 and 4.2 only] Implicit none in module overwrite explicit in procedure
--- Comment #4 from pault at gcc dot gnu dot org 2007-01-14 11:05 --- (In reply to comment #3) > Subject: Bug 24783 > > Author: aldot > Date: Mon Nov 20 16:20:33 2006 > New Revision: 119016 Bernhard, Are you going to apply this to 4.2, or do you want me to do it? It would be nice to clear the PR. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24783
[Bug fortran/30437] [4.0/4.1/4.2/4.3 Regression] -Wno-all is rejected (even when fortran is not included)
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-14 11:13 --- Why Wall is not in common.opt ? As far as I know, that would be the right fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30437
[Bug target/30413] %z produces ICE for char operands
--- Comment #4 from uros at gcc dot gnu dot org 2007-01-14 11:14 --- Subject: Bug 30413 Author: uros Date: Sun Jan 14 11:14:20 2007 New Revision: 120769 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120769 Log: PR target/30413 * config/i386/i386.c (print_operand) ['z']: Output 'b' for operands of size 1. testsuite/ChangeLog: PR target/30413 * gcc.target/i386/pr30413.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr30413.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30413
[Bug fortran/29410] [4.2 only] bug with TRANSFER() and -O2
--- Comment #10 from pault at gcc dot gnu dot org 2007-01-14 11:19 --- (In reply to comment #9) > It turns out my fix caused PR 29951 which I am testing a fix for PR 29951 > now. > My new patch does not break this testcase which is a good sign. > Andrew, Were you going to apply this to 4.2, together with revision 119211, or will you close them as fixed on 4.3? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29410
[Bug target/30413] %z produces ICE for char operands
--- Comment #5 from ubizjak at gmail dot com 2007-01-14 11:32 --- Although %zN is not documented, we advertise it in config/i386/i386.md: ;; The special asm out single letter directives following a '%' are: ;; 'z' mov%z1 would be movl, movw, or movb depending on the mode of ;; operands[1]. The fix is straightforward and doesn't hurt anything. I have fixed this for 4.3.0. BTW: The same binary code can be achieved by using plain "mov", as gas figures out opcode from register name. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Known to work||4.3.0 Last reconfirmed|2007-01-14 06:02:37 |2007-01-14 11:32:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30413
[Bug fortran/24783] [4.1 and 4.2 only] Implicit none in module overwrite explicit in procedure
--- Comment #5 from aldot at gcc dot gnu dot org 2007-01-14 11:37 --- > Bernhard, > > Are you going to apply this to 4.2, or do you want me to do it? It would be > nice to clear the PR. Please feel free to backport this and (eventually) all other i left unfixed for non-trunk versions that you may want to fix. Thank you very much for your time! PS: Also, feel free to (re-)assign them to you, of course. cheers, > > Paul > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24783
[Bug fortran/30235] [4.1 and 4.2] missing alternate return argument with explicit interface causes segfault
--- Comment #7 from pault at gcc dot gnu dot org 2007-01-14 11:42 --- (In reply to comment #6) > Fixed on trunk, as per commit in #4. > Brooks, Are you going to commit this to 4.2 so that we can clear it? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30235
[Bug fortran/30276] [4.2 only] gfortran include problem
--- Comment #9 from pault at gcc dot gnu dot org 2007-01-14 11:45 --- (In reply to comment #7) > Fixed in 4.3; I will commit the patch for 4.2 in about a week; I will not fix > 4.1. > Tobias, Are you in a position to do that now? The week is up and all is well:) Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30276
[Bug fortran/29786] [4.1/4.2/4.3 Regression] rejects equivalence
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-14 13:32 ---
I do not seem able to fix the problem with attachments on my machine...
Following yesterday's discussion on the list,
trans-common.c:445
switch (e->ts.type)
{
case BT_INTEGER:
if (WORDS_BIG_ENDIAN)
gfc_conv_mpz_to_integers (e->value.integer,
&buffer[0], &buffer[1]);
else
gfc_conv_mpz_to_integers (e->value.integer,
&buffer[1], &buffer[0]);
memcpy (data, buffer, len);
return;
to replace the BT_INTEGER case in the attachment should do the job.
It needs testing now on 64 bit machines with both endian-nesses.
Brooks, I have reassigned this PR to you; I am very happy to help
out/collaborate on it but I think you are right - I just do not have the time
to see it through, right now.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|pault at gcc dot gnu dot org|brooks at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug fortran/29786] [4.1/4.2/4.3 Regression] rejects equivalence
--- Comment #6 from pault at gcc dot gnu dot org 2007-01-14 13:42 --- Forget the previous; it's wrong! It does indicate that WORDS_BIG_ENDIAN and friends are available, however. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug driver/30460] [4.0/4.1/4.2/4.3 Regression] asm_debug is not initialized in gcc.c when using a "default" specs file
--- Comment #7 from rschiele at gmail dot com 2007-01-14 13:52 --- Created an attachment (id=12904) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12904&action=view) new version of the fix This implements my new suggestion on how to fix this. Any comments? -- rschiele at gmail dot com changed: What|Removed |Added Attachment #12903|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30460
[Bug c/30439] Intended Behaviour? #include searches for signal.h in local directory
--- Comment #7 from andersin at freenet dot de 2007-01-14 14:28 --- Your are correct, I have C_INCLUDE_PATH set (sorry I forgot to mention it). I did not think it important, but it is. If C_INCLUDE_PATH ends with a colon, compilation fails. Removing the colon is not a problem in general, but in my special case it is happening because it is set up in my .bashrc like so: export C_INCLUDE_PATH=/home/cbs/local/include:$C_INCLUDE_PATH, so I do not see a way of properly doing it save for checking if C_INCLUDE_PATH is empty before adding to it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30439
[Bug fortran/30410] Host association bug w/ EXTERNAL
--- Comment #4 from pault at gcc dot gnu dot org 2007-01-14 14:43 --- Subject: Bug 30410 Author: pault Date: Sun Jan 14 14:43:08 2007 New Revision: 120771 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120771 Log: 2007-01-14 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30410 * trans-decl.c (gfc_sym_mangled_function_id): Module, external symbols must not have the module name prepended. 2007-01-14 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30410 * gfortran.dg/external_procedures_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/external_procedures_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30410
[Bug fortran/23232] [4.2 and 4.1 only] DATA implied DO variables
--- Comment #10 from pault at gcc dot gnu dot org 2007-01-14 14:50 --- Subject: Bug 23232 Author: pault Date: Sun Jan 14 14:49:50 2007 New Revision: 120772 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120772 Log: 2007-01-14 Jerry DeLisle <[EMAIL PROTECTED]> Paul Thomas <[EMAIL PROTECTED]> Back port from trunk PR fortran/30408 * lang.opt: Add Wcharacter_truncation option. * options.c (gfc_init_options): Initialize gfc_option.warn_character_truncation to zero. (gfc_handle_option): Add case for OPT_Wcharacter_truncation. PR fortran/30408 * resolve.c (resolve_code): Use the code->expr character length directly to set length of llen. 2007-01-14 Paul Thomas <[EMAIL PROTECTED]> Backports from trunk PR fortran/23232 * decl.c (gfc_in_match_data, gfc_set_in_match_data): New functions to signal that a DATA statement is being matched. (gfc_match_data): Call gfc_set_in_match_data on entry and on exit. * gfortran.h : Add prototypes for above. * expr.c (check_init_expr): Avoid check on parameter or variable if gfc_in_match_data is true. (gfc_match_init_expr): Do not call error on non-reduction of expression if gfc_in_match_data is true. PR fortran/27996 PR fortran/27998 * decl.c (gfc_set_constant_character_len): Add boolean arg to flag array constructor resolution. Warn if string is being truncated. Standard dependent error if string is padded. Set new arg to false for all three calls to gfc_set_constant_character_len. * match.h : Add boolean arg to prototype for gfc_set_constant_character_len. * gfortran.h : Add warn_character_truncation to gfc_options. * options.c (set_Wall): Set warn_character_truncation if -Wall is set. * resolve.c (resolve_code): Warn if rhs string in character assignment has to be truncated. * array.c (gfc_resolve_character_array_constructor): Set new argument to true for call to gfc_set_constant_character_len. PR fortran/30410 * trans-decl.c (gfc_sym_mangled_function_id): Module, external symbols must not have the module name prepended. 2007-01-14 Paul Thomas <[EMAIL PROTECTED]> PR fortran/23232 * gfortran.dg/data_implied_do_1.f90: New test. PR fortran/27996 PR fortran/27998 * gfortran.dg/char_length_1.f90: New test. PR fortran/30410 * gfortran.dg/external_procedures_2.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/char_length_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/data_implied_do_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/external_procedures_2.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/array.c branches/gcc-4_2-branch/gcc/fortran/decl.c branches/gcc-4_2-branch/gcc/fortran/expr.c branches/gcc-4_2-branch/gcc/fortran/gfortran.h branches/gcc-4_2-branch/gcc/fortran/lang.opt branches/gcc-4_2-branch/gcc/fortran/match.h branches/gcc-4_2-branch/gcc/fortran/options.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-decl.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23232
[Bug fortran/30410] Host association bug w/ EXTERNAL
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-14 14:50 --- Subject: Bug 30410 Author: pault Date: Sun Jan 14 14:49:50 2007 New Revision: 120772 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120772 Log: 2007-01-14 Jerry DeLisle <[EMAIL PROTECTED]> Paul Thomas <[EMAIL PROTECTED]> Back port from trunk PR fortran/30408 * lang.opt: Add Wcharacter_truncation option. * options.c (gfc_init_options): Initialize gfc_option.warn_character_truncation to zero. (gfc_handle_option): Add case for OPT_Wcharacter_truncation. PR fortran/30408 * resolve.c (resolve_code): Use the code->expr character length directly to set length of llen. 2007-01-14 Paul Thomas <[EMAIL PROTECTED]> Backports from trunk PR fortran/23232 * decl.c (gfc_in_match_data, gfc_set_in_match_data): New functions to signal that a DATA statement is being matched. (gfc_match_data): Call gfc_set_in_match_data on entry and on exit. * gfortran.h : Add prototypes for above. * expr.c (check_init_expr): Avoid check on parameter or variable if gfc_in_match_data is true. (gfc_match_init_expr): Do not call error on non-reduction of expression if gfc_in_match_data is true. PR fortran/27996 PR fortran/27998 * decl.c (gfc_set_constant_character_len): Add boolean arg to flag array constructor resolution. Warn if string is being truncated. Standard dependent error if string is padded. Set new arg to false for all three calls to gfc_set_constant_character_len. * match.h : Add boolean arg to prototype for gfc_set_constant_character_len. * gfortran.h : Add warn_character_truncation to gfc_options. * options.c (set_Wall): Set warn_character_truncation if -Wall is set. * resolve.c (resolve_code): Warn if rhs string in character assignment has to be truncated. * array.c (gfc_resolve_character_array_constructor): Set new argument to true for call to gfc_set_constant_character_len. PR fortran/30410 * trans-decl.c (gfc_sym_mangled_function_id): Module, external symbols must not have the module name prepended. 2007-01-14 Paul Thomas <[EMAIL PROTECTED]> PR fortran/23232 * gfortran.dg/data_implied_do_1.f90: New test. PR fortran/27996 PR fortran/27998 * gfortran.dg/char_length_1.f90: New test. PR fortran/30410 * gfortran.dg/external_procedures_2.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/char_length_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/data_implied_do_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/external_procedures_2.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/array.c branches/gcc-4_2-branch/gcc/fortran/decl.c branches/gcc-4_2-branch/gcc/fortran/expr.c branches/gcc-4_2-branch/gcc/fortran/gfortran.h branches/gcc-4_2-branch/gcc/fortran/lang.opt branches/gcc-4_2-branch/gcc/fortran/match.h branches/gcc-4_2-branch/gcc/fortran/options.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-decl.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30410
[Bug fortran/27998] [4.2 and 4.1 only] character arrays: warn if erray constructor values have different lengths
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-14 14:50 --- Subject: Bug 27998 Author: pault Date: Sun Jan 14 14:49:50 2007 New Revision: 120772 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120772 Log: 2007-01-14 Jerry DeLisle <[EMAIL PROTECTED]> Paul Thomas <[EMAIL PROTECTED]> Back port from trunk PR fortran/30408 * lang.opt: Add Wcharacter_truncation option. * options.c (gfc_init_options): Initialize gfc_option.warn_character_truncation to zero. (gfc_handle_option): Add case for OPT_Wcharacter_truncation. PR fortran/30408 * resolve.c (resolve_code): Use the code->expr character length directly to set length of llen. 2007-01-14 Paul Thomas <[EMAIL PROTECTED]> Backports from trunk PR fortran/23232 * decl.c (gfc_in_match_data, gfc_set_in_match_data): New functions to signal that a DATA statement is being matched. (gfc_match_data): Call gfc_set_in_match_data on entry and on exit. * gfortran.h : Add prototypes for above. * expr.c (check_init_expr): Avoid check on parameter or variable if gfc_in_match_data is true. (gfc_match_init_expr): Do not call error on non-reduction of expression if gfc_in_match_data is true. PR fortran/27996 PR fortran/27998 * decl.c (gfc_set_constant_character_len): Add boolean arg to flag array constructor resolution. Warn if string is being truncated. Standard dependent error if string is padded. Set new arg to false for all three calls to gfc_set_constant_character_len. * match.h : Add boolean arg to prototype for gfc_set_constant_character_len. * gfortran.h : Add warn_character_truncation to gfc_options. * options.c (set_Wall): Set warn_character_truncation if -Wall is set. * resolve.c (resolve_code): Warn if rhs string in character assignment has to be truncated. * array.c (gfc_resolve_character_array_constructor): Set new argument to true for call to gfc_set_constant_character_len. PR fortran/30410 * trans-decl.c (gfc_sym_mangled_function_id): Module, external symbols must not have the module name prepended. 2007-01-14 Paul Thomas <[EMAIL PROTECTED]> PR fortran/23232 * gfortran.dg/data_implied_do_1.f90: New test. PR fortran/27996 PR fortran/27998 * gfortran.dg/char_length_1.f90: New test. PR fortran/30410 * gfortran.dg/external_procedures_2.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/char_length_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/data_implied_do_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/external_procedures_2.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/array.c branches/gcc-4_2-branch/gcc/fortran/decl.c branches/gcc-4_2-branch/gcc/fortran/expr.c branches/gcc-4_2-branch/gcc/fortran/gfortran.h branches/gcc-4_2-branch/gcc/fortran/lang.opt branches/gcc-4_2-branch/gcc/fortran/match.h branches/gcc-4_2-branch/gcc/fortran/options.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-decl.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27998
[Bug fortran/30408] [gfortran, 4.3 regression]: ICE on valid with -Wall
--- Comment #7 from pault at gcc dot gnu dot org 2007-01-14 14:50 --- Subject: Bug 30408 Author: pault Date: Sun Jan 14 14:49:50 2007 New Revision: 120772 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120772 Log: 2007-01-14 Jerry DeLisle <[EMAIL PROTECTED]> Paul Thomas <[EMAIL PROTECTED]> Back port from trunk PR fortran/30408 * lang.opt: Add Wcharacter_truncation option. * options.c (gfc_init_options): Initialize gfc_option.warn_character_truncation to zero. (gfc_handle_option): Add case for OPT_Wcharacter_truncation. PR fortran/30408 * resolve.c (resolve_code): Use the code->expr character length directly to set length of llen. 2007-01-14 Paul Thomas <[EMAIL PROTECTED]> Backports from trunk PR fortran/23232 * decl.c (gfc_in_match_data, gfc_set_in_match_data): New functions to signal that a DATA statement is being matched. (gfc_match_data): Call gfc_set_in_match_data on entry and on exit. * gfortran.h : Add prototypes for above. * expr.c (check_init_expr): Avoid check on parameter or variable if gfc_in_match_data is true. (gfc_match_init_expr): Do not call error on non-reduction of expression if gfc_in_match_data is true. PR fortran/27996 PR fortran/27998 * decl.c (gfc_set_constant_character_len): Add boolean arg to flag array constructor resolution. Warn if string is being truncated. Standard dependent error if string is padded. Set new arg to false for all three calls to gfc_set_constant_character_len. * match.h : Add boolean arg to prototype for gfc_set_constant_character_len. * gfortran.h : Add warn_character_truncation to gfc_options. * options.c (set_Wall): Set warn_character_truncation if -Wall is set. * resolve.c (resolve_code): Warn if rhs string in character assignment has to be truncated. * array.c (gfc_resolve_character_array_constructor): Set new argument to true for call to gfc_set_constant_character_len. PR fortran/30410 * trans-decl.c (gfc_sym_mangled_function_id): Module, external symbols must not have the module name prepended. 2007-01-14 Paul Thomas <[EMAIL PROTECTED]> PR fortran/23232 * gfortran.dg/data_implied_do_1.f90: New test. PR fortran/27996 PR fortran/27998 * gfortran.dg/char_length_1.f90: New test. PR fortran/30410 * gfortran.dg/external_procedures_2.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/char_length_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/data_implied_do_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/external_procedures_2.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/array.c branches/gcc-4_2-branch/gcc/fortran/decl.c branches/gcc-4_2-branch/gcc/fortran/expr.c branches/gcc-4_2-branch/gcc/fortran/gfortran.h branches/gcc-4_2-branch/gcc/fortran/lang.opt branches/gcc-4_2-branch/gcc/fortran/match.h branches/gcc-4_2-branch/gcc/fortran/options.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-decl.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30408
[Bug fortran/27996] [4.2 and 4.1 only] Compile time warn for: character(2) :: str = 'ABC' (expression truncated)
--- Comment #4 from pault at gcc dot gnu dot org 2007-01-14 14:50 --- Subject: Bug 27996 Author: pault Date: Sun Jan 14 14:49:50 2007 New Revision: 120772 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120772 Log: 2007-01-14 Jerry DeLisle <[EMAIL PROTECTED]> Paul Thomas <[EMAIL PROTECTED]> Back port from trunk PR fortran/30408 * lang.opt: Add Wcharacter_truncation option. * options.c (gfc_init_options): Initialize gfc_option.warn_character_truncation to zero. (gfc_handle_option): Add case for OPT_Wcharacter_truncation. PR fortran/30408 * resolve.c (resolve_code): Use the code->expr character length directly to set length of llen. 2007-01-14 Paul Thomas <[EMAIL PROTECTED]> Backports from trunk PR fortran/23232 * decl.c (gfc_in_match_data, gfc_set_in_match_data): New functions to signal that a DATA statement is being matched. (gfc_match_data): Call gfc_set_in_match_data on entry and on exit. * gfortran.h : Add prototypes for above. * expr.c (check_init_expr): Avoid check on parameter or variable if gfc_in_match_data is true. (gfc_match_init_expr): Do not call error on non-reduction of expression if gfc_in_match_data is true. PR fortran/27996 PR fortran/27998 * decl.c (gfc_set_constant_character_len): Add boolean arg to flag array constructor resolution. Warn if string is being truncated. Standard dependent error if string is padded. Set new arg to false for all three calls to gfc_set_constant_character_len. * match.h : Add boolean arg to prototype for gfc_set_constant_character_len. * gfortran.h : Add warn_character_truncation to gfc_options. * options.c (set_Wall): Set warn_character_truncation if -Wall is set. * resolve.c (resolve_code): Warn if rhs string in character assignment has to be truncated. * array.c (gfc_resolve_character_array_constructor): Set new argument to true for call to gfc_set_constant_character_len. PR fortran/30410 * trans-decl.c (gfc_sym_mangled_function_id): Module, external symbols must not have the module name prepended. 2007-01-14 Paul Thomas <[EMAIL PROTECTED]> PR fortran/23232 * gfortran.dg/data_implied_do_1.f90: New test. PR fortran/27996 PR fortran/27998 * gfortran.dg/char_length_1.f90: New test. PR fortran/30410 * gfortran.dg/external_procedures_2.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/char_length_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/data_implied_do_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/external_procedures_2.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/array.c branches/gcc-4_2-branch/gcc/fortran/decl.c branches/gcc-4_2-branch/gcc/fortran/expr.c branches/gcc-4_2-branch/gcc/fortran/gfortran.h branches/gcc-4_2-branch/gcc/fortran/lang.opt branches/gcc-4_2-branch/gcc/fortran/match.h branches/gcc-4_2-branch/gcc/fortran/options.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-decl.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27996
[Bug fortran/23232] [4.1 only] DATA implied DO variables
--- Comment #11 from pault at gcc dot gnu dot org 2007-01-14 14:51 --- Fixed on trunk and 4.2 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.2 and 4.1 only] DATA |[4.1 only] DATA implied DO |implied DO variables|variables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23232
[Bug fortran/27996] [4.1 only] Compile time warn for: character(2) :: str = 'ABC' (expression truncated)
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-14 14:52 --- Fixed on trunk and 4.2 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.2 and 4.1 only] Compile |[4.1 only] Compile time warn |time warn for: character(2)|for: character(2) :: str = |:: str = 'ABC' (expression |'ABC' (expression truncated) |truncated) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27996
[Bug fortran/27998] [4.1 only] character arrays: warn if erray constructor values have different lengths
--- Comment #6 from pault at gcc dot gnu dot org 2007-01-14 14:53 --- Fixed on trunk and 4.2 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.2 and 4.1 only] character|[4.1 only] character arrays: |arrays: warn if erray |warn if erray constructor |constructor values have |values have different |different lengths |lengths http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27998
[Bug fortran/30410] Host association bug w/ EXTERNAL
--- Comment #6 from pault at gcc dot gnu dot org 2007-01-14 14:55 --- Fixed on trunk and 4.2 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30410
[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory
--- Comment #23 from rguenth at gcc dot gnu dot org 2007-01-14 15:06 --- Can it be the patch changes result of alias analysis? I get (big) runtime differences (but maybe due to unrelated changes) with the tester from Jan 13 (patched) vs. Jan 14 (unpatched). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
[Bug middle-end/30403] [4.3 Regression] libssp/ssp.c:177: ICE: in cgraph_expand_function, at cgraphunit.c:973
--- Comment #3 from danglin at gcc dot gnu dot org 2007-01-14 15:20 --- Yes, this is fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30403
[Bug middle-end/30322] ((-i-1) + i) +1) is turned into ~i + (i+1) and never into 0 on the tree level
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-01-14 16:12 --- This is now fixed for tramp3d. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.3.0 Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30322
[Bug testsuite/24107] gcc.dg/20050922-1.c relies in stdint.h
--- Comment #8 from danglin at gcc dot gnu dot org 2007-01-14 17:25 --- Subject: Bug 24107 Author: danglin Date: Sun Jan 14 17:25:05 2007 New Revision: 120776 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120776 Log: PR testsuite/24107 Backport from mainline 2005-10-24 Paul Brook <[EMAIL PROTECTED]> * gcc.dg/20050922-1.c: Provide definition of uint32_t without using stdint.h. Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/20050922-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24107
[Bug c/30439] Intended Behaviour? #include searches for signal.h in local directory
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-14 18:21 --- "a:" means have a and the current directory. So this is not a bug, C_INCLUDE_PATH acts just like PATH in that an empty argument after the colon means the current directory. >export C_INCLUDE_PATH=/home/cbs/local/include:$C_INCLUDE_PATH, so I do not see > a way of properly doing it save for checking if C_INCLUDE_PATH is empty before > adding to it. There are a bunches of way of checking if C_INCLUDE_PATH is set, like $(?C_INCLUDE_PATH) I think will tell you if it is set or not. This is not the right forum to ask about shell programming really. -- 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=30439
[Bug objc/30461] New: Class methods should be marked as hidden
As no one call call the class methods of Objc directly, they should be marked as hidden so that they bind locally in a shared library. -- Summary: Class methods should be marked as hidden Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: objc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30461
[Bug objc/30461] Class methods should be marked as hidden
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30461
[Bug libobjc/30462] New: libobjc public headers should be wrapped with #pragam visibilitity push(defualt)/pop
The libobjc public headers should be wrapped with #pragam visibilitity push(defualt)/pop so that people (and libobjc) can use -fvisibility=hidden. -- Summary: libobjc public headers should be wrapped with #pragam visibilitity push(defualt)/pop Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30462
[Bug libobjc/30462] libobjc public headers should be wrapped with #pragam visibilitity push(defualt)/pop
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-14 19:10 --- Mine, working on it. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-14 19:10:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30462
[Bug libstdc++/30463] New: [regression] -Wconversion triggers
Consider the following program:
#include
void f() {
std::vector v;
v.push_back(1);
}
-Wconversion now (as of 2007-01-14) triggers the following warning in
the libstdc++ headers:
/suse/gp/gcc-i686/lib/gcc/i686-suse-linux/4.3.0/../../../../include/c++/4.3.0/bits/stl_vector.h:
In destructor 'std::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp = int,
_Alloc = std::allocator]':
/suse/gp/gcc-i686/lib/gcc/i686-suse-linux/4.3.0/../../../../include/c++/4.3.0/bits/stl_vector.h:199:
instantiated from 'std::vector<_Tp, _Alloc>::vector(const _Alloc&) [with _Tp
= int, _Alloc = std::allocator]'
x.cc:4: instantiated from here
/suse/gp/gcc-i686/lib/gcc/i686-suse-linux/4.3.0/../../../../include/c++/4.3.0/bits/stl_vector.h:120:
warning: conversion to 'unsigned int' from 'int' may alter its value
/suse/gp/gcc-i686/lib/gcc/i686-suse-linux/4.3.0/../../../../include/c++/4.3.0/bits/vector.tcc:
In member function 'void std::vector<_Tp,
_Alloc>::_M_insert_aux(__gnu_cxx::__normal_iterator::_Tp_alloc_type::pointer, std::vector<_Tp,
_Alloc> >, const _Tp&) [with _Tp = int, _Alloc = std::allocator]':
/suse/gp/gcc-i686/lib/gcc/i686-suse-linux/4.3.0/../../../../include/c++/4.3.0/bits/stl_vector.h:605:
instantiated from 'void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with
_Tp = int, _Alloc = std::allocator]'
x.cc:6: instantiated from here
/suse/gp/gcc-i686/lib/gcc/i686-suse-linux/4.3.0/../../../../include/c++/4.3.0/bits/vector.tcc:295:
warning: conversion to 'unsigned int' from 'int' may alter its value
This is bad. Our own headers should not trigger such warnings when a
user enables them for his own code.
--
Summary: [regression] -Wconversion triggers
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gerald at pfeifer dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30463
[Bug libstdc++/30464] New: [regression] -Wconversion triggers warnings for deque<>
Consider the following program:
#include
void f() {
std::deque d;
d.push_back(1);
}
-Wconversion now (as of 2007-01-14) triggers the following warning in
the libstdc++ headers:
/suse/gp/gcc-i686/lib/gcc/i686-suse-linux/4.3.0/../../../../include/c++/4.3.0/bits/deque.tcc:
In member function 'void std::deque<_Tp, _Alloc>::_M_reallocate_map(size_t,
bool) [with _Tp = int, _Alloc = std::allocator]':
/suse/gp/gcc-i686/lib/gcc/i686-suse-linux/4.3.0/../../../../include/c++/4.3.0/bits/stl_deque.h:1520:
instantiated from 'void std::deque<_Tp,
_Alloc>::_M_reserve_map_at_back(size_t) [with _Tp = int, _Alloc =
std::allocator]'
/suse/gp/gcc-i686/lib/gcc/i686-suse-linux/4.3.0/../../../../include/c++/4.3.0/bits/deque.tcc:308:
instantiated from 'void std::deque<_Tp, _Alloc>::_M_push_back_aux(const _Tp&)
[with _Tp = int, _Alloc = std::allocator]'
/suse/gp/gcc-i686/lib/gcc/i686-suse-linux/4.3.0/../../../../include/c++/4.3.0/bits/stl_deque.h:1062:
instantiated from 'void std::deque<_Tp, _Alloc>::push_back(const _Tp&) [with
_Tp = int, _Alloc = std::allocator]'
x.cc:6: instantiated from here
/suse/gp/gcc-i686/lib/gcc/i686-suse-linux/4.3.0/../../../../include/c++/4.3.0/bits/deque.tcc:714:
warning: conversion to 'size_t' from 'int' may alter its value
--
Summary: [regression] -Wconversion triggers warnings for deque<>
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gerald at pfeifer dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
[Bug other/30465] New: Duplicated overflow warning
paolo:~/Work> more warning.cc
int main()
{
wchar_t wc = ((wchar_t)1 << 31) - 1;
}
paolo:~/Work> g++ warning.cc
warning.cc: In function 'int main()':
warning.cc:3: warning: integer overflow in expression
warning.cc:3: warning: overflow in implicit constant conversion
--
Summary: Duplicated overflow warning
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30465
[Bug fortran/30352] [4.1, 4.2 only] False error on INTENT(IN) when modifying pointees
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-14 21:41 --- This is indeed fixed. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30352
[Bug libstdc++/30464] [regression] -Wconversion triggers warnings for deque<>::push_back()
--- Comment #1 from manu at gcc dot gnu dot org 2007-01-14 23:03 --- Gerald, One thing is whether the warning was incorrect or not. Looking at the code and the definition of Wconversion, what do you think? Another thing is whether we want or not to emit warnings for libstdc++. I don't know how I can prevent this. I believed warnings in system headers were handled automatically by the -Wsystem-headers option. So I guess this is not a system header. -- 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=30464
[Bug libstdc++/30464] [regression] -Wconversion triggers warnings for deque<>::push_back()
--- Comment #2 from pcarlini at suse dot de 2007-01-14 23:08 --- (In reply to comment #1) > ...So I guess this is not a system header. In fact, it *is* a system header :-( See my message to gcc@ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
[Bug libstdc++/30464] [regression] -Wconversion triggers warnings for deque<>::push_back()
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-14 23:15 --- So I cannot understand why are we warning. Warnings in system headers should only be emitted when using -Wsystem-headers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
[Bug libstdc++/30464] [regression] -Wconversion triggers warnings for deque<>::push_back()
--- Comment #4 from pcarlini at suse dot de 2007-01-14 23:22 --- (In reply to comment #3) > So I cannot understand why are we warning. Warnings in system headers should > only be emitted when using -Wsystem-headers. Did you read my reply? Again: the system_header pragma does *not* work with templates! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
[Bug libstdc++/30464] [regression] -Wconversion triggers warnings for deque<>::push_back()
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-14 23:37 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
[Bug libstdc++/30464] [regression] -Wconversion triggers warnings for deque<>::push_back()
--- Comment #6 from pcarlini at suse dot de 2007-01-15 00:30 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
[Bug java/30466] New: gcj crashes when using invalid options
gcj crashes when invoking like 'gcj -Msomething -MT something SomeFile.java' where SomeFile.java could be any existing file, even empty. OUTPUT: $ gcj -Manything -MT anything Test.java -v Using built-in specs. Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libgcj.spec rename spec lib to liborig gcj: unrecognized option '-Manything' Target: i686-pc-linux-gnu Configured with: ../gcc-4.1-20061215/configure --prefix=/usr --enable-shared --enable-languages=java --enable-threads=posix --enable-__cxa_atexit --enable-java-awt=gtk --libdir=/usr/lib --disable-multilib --enable-clocale=gnu --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre Thread model: posix gcc version 4.1.2 20061215 (prerelease) /usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/jc1 Test.java -fhash-synchronization -fno-use-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -quiet -dumpbase Test.java -mtune=pentiumpro -auxbase Test -g1 -version -MT anything -o /tmp/ccpXTZV8.s GNU Java version 4.1.2 20061215 (prerelease) (i686-pc-linux-gnu) compiled by GNU C version 4.1.2 20061215 (prerelease). GGC heuristics: --param ggc-min-expand=55 --param ggc-min-heapsize=48233 Class path starts here: ./ /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/lib/ /usr/share/java/libgcj-4.1.2.jar/ (system) (zip) jc1: ../../gcc-4.1-20061215/gcc/java/jcf-depend.c:135: jcf_dependency_write: Assertion `dependencies' failed. Test.java:1: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: gcj crashes when using invalid options Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: davorin dot ucakar at gmail dot com GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30466
[Bug bootstrap/30467] New: [4.3 regression] Bootstrap failure on i386
I am seeing the following bootstrap failure on i386, both i386-unknown-freebsd5.4 and i386-suse-linux. i686 does not have this issue on both systems. /tmp/OBJ-0114-2254/./prev-gcc/xgcc -B/tmp/OBJ-0114-2254/./prev-gcc/ -B/suse/gp/gcc-i686/i386-suse-linux/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I/mounts/users-space/gp/gcc/trunk/gcc -I/mounts/users-space/gp/gcc/trunk/gcc/. -I/mounts/users-space/gp/gcc/trunk/gcc/../include -I/mounts/users-space/gp/gcc/trunk/gcc/../libcpp/include -I/mounts/users-space/gp/gcc/trunk/gcc/../libdecnumber -I../libdecnumber /mounts/users-space/gp/gcc/trunk/gcc/varasm.c -o varasm.o /mounts/users-space/gp/gcc/trunk/gcc/tree.c: In function 'recompute_tree_invariant_for_addr_expr': /mounts/users-space/gp/gcc/trunk/gcc/tree.c:2871: 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. -- Summary: [4.3 regression] Bootstrap failure on i386 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gerald at pfeifer dot com GCC host triplet: i386-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30467
[Bug bootstrap/30467] [4.3 regression] Bootstrap failure on i386
--- Comment #1 from hubicka at gcc dot gnu dot org 2007-01-15 01:56 --- since the bug does not reproduce on Linux setup, would be possible to have preprocessed testcase and possibly also backtrace of the crash? Thank you, Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30467
[Bug bootstrap/30467] [4.3 regression] Bootstrap failure on i386
--- Comment #2 from gerald at pfeifer dot com 2007-01-15 02:06 --- It does reproduce on openSUSE 10.2 for me when I configure with --disable-libgcj i386-suse-linux I am kicking off a new bootstrap and will provide pre-processed sources tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30467
[Bug preprocessor/30468] New: -M not fully chops dirname
I see -M option for gcc-4.1.1 output chops dirname, but faces below problem. $ cat foo.c #include "foo.h" $ cat Include/foo.h /* empty */ $ gcc41 -M -I.//Include foo.c foo.o: foo.c /Include/foo.h ^ root? gcc-3.4.4 output was: $ gcc -M -I.//Include foo.c foo.o: foo.c .//Include/foo.h -- Summary: -M not fully chops dirname Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kaminaga at sm dot sony dot co dot jp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30468
[Bug bootstrap/30469] New: [4.3 Regression] profiledbootstrap no longer works
When doing a "make profiledbootstrap", -fprofile-generate is used for libgcc which is wrong. -- Summary: [4.3 Regression] profiledbootstrap no longer works Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30469
[Bug bootstrap/30469] [4.3 Regression] profiledbootstrap no longer works
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-15 02:29 --- This was reported here: http://gcc.gnu.org/ml/java/2007-01/msg00050.html And I was able to reproduce it with just --enable-languages=c, make profiledbootstrap on i686-linux-gnu. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30469
[Bug preprocessor/30468] [4.0/4.1/4.2/4.3 Regression] -M not fully chops dirname
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-15 02:34 --- Confirmed. -- 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 Known to fail|4.1.1 |4.1.1 4.0.0 4.0.2 4.3.0 Known to work|3.4.4 |3.4.4 3.4.0 Last reconfirmed|-00-00 00:00:00 |2007-01-15 02:34:25 date|| Summary|-M not fully chops dirname |[4.0/4.1/4.2/4.3 Regression] ||-M not fully chops dirname Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30468
[Bug bootstrap/30467] [4.3 regression] Bootstrap failure on i386
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30467
[Bug rtl-optimization/30467] [4.3 regression] Bootstrap failure on i386
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-15 03:34 --- The ICE is happens at ifcvt.c:1901. if_info->insn_b is NULL. It looks like it was caused by: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00704.html Looking to reduce the testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org Component|bootstrap |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30467
[Bug rtl-optimization/30467] [4.3 regression] Bootstrap failure on i386
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-15 05:27 ---
Reduced testcase:
struct a
{
unsigned a:7;
unsigned b:1;
};
void g(char*);
void f(struct a *t)
{
char t1 = 1;
if (!t->b)
t1 = 0;
g(&t1);
}
--
pinskia 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 05:27:59
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30467
[Bug rtl-optimization/30467] [4.3 regression] Bootstrap failure on i386
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-01-15 05:27:59 |2007-01-15 06:25:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30467
[Bug middle-end/28071] [4.1 regression] A file that can not be compiled in reasonable time/space
--- Comment #56 from zaks at il dot ibm dot com 2007-01-15 07:19 ---
(In reply to comment #55)
> Created an attachment (id=12879)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12879&action=view) [edit]
> Patch for scheduler dependency lists.
Looks like a pretty good cleanup IMHO. Here are some comments.
o dep_def: representing a dependence edge including both producer and consumer
is very handy, albeit somewhat redundant as we're usually traversing all cons
connected to a pro or vice versa. (I.e., has its pros and cons, but mostly pros
I agree - also done in ddg.h/ddg_edge.) Maybe comment why both 'kind' and 'ds'
are needed, as one supersedes the other.
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 "/*
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?
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.
o To add to the checking routines, the following can be checked: every
dep_node_def is pointed-to by either its data->back xor its data->forw, right?
If so, this can be used to identify if a dep_node_def is forward or backward;
that all nodes on a list are forward (and share the same pro) or backward (and
share the same con); and to assert the following regarding L:
+/* Add a dependency described by DEP to the list L.
+ L should be either INSN_DEPS1 or RESOLVED_DEPS1. */
o insn_cost (insn, dep): maybe it's better to break this into insn_cost (insn)
of a producer regardless of consumers, and "dep_cost (dep)".
o The comment explaining what 'resolve_dep' does can be inlined together with
its code.
+/* Detach dep_node N from the list. */
+static void
+dep_node_detach (dep_node_t n)
+{
+ dep_node_t *prev_nextp = DEP_NODE_PREV_NEXTP (n);
+ dep_node_t next = DEP_NODE_NEXT (n);
+
+ *prev_nextp = next;
+
+ if (next != NULL)
+DEP_NODE_PREV_NEXTP (next) = prev_nextp;
maybe complete the detachment by adding:
DEP_NODE_PREV_NEXTP (n) = NULL;
DEP_NODE_NEXT (n) = NULL;
+}
+/* Attach NEXT to the next field pointed to by PREV_NEXTP. */
^^^N to appear after node X whose &DEP_NODE_NEXT (X) is given by
PREV_NEXT_P
+static void
+dep_node_attach (dep_node_t n, dep_node_t *prev_nextp)
better place
+dep_node_check_p (dep_node_t n)
next to
+dep_nodes_check_p (dep_node_t n)
+/* Make a copy of FROM in TO with substitutin consumer with CON.
^^substituting consumer with CON.
Ayal.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug rtl-optimization/30467] [4.3 regression] Bootstrap failure: ICE in ifcvt.c
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-01-15 07:24 --- Reproducible on i586-linux. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org GCC build triplet||i[345]86-linux GCC host triplet|i386-suse-linux |i[345]86-linux GCC target triplet||i[345]86-linux Summary|[4.3 regression] Bootstrap |[4.3 regression] Bootstrap |failure on i386, ICE in |failure: ICE in ifcvt.c |ifcvt.c | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30467
Re: [Bug middle-end/28071] [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) and making code more
transparent. Below are my comments on yours:
zaks at il dot ibm dot com wrote:
--- Comment #56 from zaks at il dot ibm dot com 2007-01-15 07:19 ---
(In reply to comment #55)
Created an attachment (id=12879)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12879&action=view) [edit]
Patch for scheduler dependency lists.
Looks like a pretty good cleanup IMHO. Here are some comments.
o dep_def: representing a dependence edge including both producer and consumer
is very handy, albeit somewhat redundant as we're usually traversing all cons
connected to a pro or vice versa.
This allows us to keep all things in one place - one of the things
current deps don't provide. I.e., when changing some property of the
dep we need to find a corresponding to that dep nodes in both backward
and forward lists and apply the change to two places instead of one.
(I.e., has its pros and cons, but mostly pros
I agree - also done in ddg.h/ddg_edge.) Maybe comment why both 'kind' and 'ds'
are needed, as one supersedes the other.
There will be. Thanks.
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.
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.
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.
o To add to the checking routines, the following can be checked: every
dep_node_def is pointed-to by either its data->back xor its data->forw, right?
If so, this can be used to identify if a dep_node_def is forward or backward;
that all nodes on a list are forward (and share the same pro) or backward (and
share the same con); and to assert the following regarding L:
+/* Add a dependency described by DEP to the list L.
+ L should be either INSN_DEPS1 or RESOLVED_DEPS1. */
Good idea.
o insn_cost (insn, dep): maybe it's better to break this into insn_cost (insn)
of a producer regardless of consumers, and "dep_cost (dep)".
Agree.
o The comment explaining what 'resolve_dep' does can be inlined together with
its code.
Agree.
+/* Detach dep_node N from the list. */
+static void
+dep_node_detach (dep_node_t n)
+{
+ dep_node_t *prev_nextp = DEP_NODE_PREV_NEXTP (n);
+ dep_node_t next = DEP_NODE_NEXT (n);
+
+ *prev_nextp = next;
+
+ if (next != NULL)
+DEP_NODE_PREV_NEXTP (next) = prev_nextp;
maybe complete the detachment by adding:
DEP_NODE_PREV_NEXTP (n) = NULL;
DEP_NODE_NEXT (n) = NULL;
Probably, you are right.
Ayal.
Thanks,
Maxim
[Bug middle-end/28071] [4.1 regression] A file that can not be compiled in reasonable time/space
--- Comment #57 from mkuvyrkov at ispras dot ru 2007-01-15 07:52 ---
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) and making code more
transparent. Below are my comments on yours:
zaks at il dot ibm dot com wrote:
> --- Comment #56 from zaks at il dot ibm dot com 2007-01-15 07:19 ---
> (In reply to comment #55)
>> Created an attachment (id=12879)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12879&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12879&action=view) [edit]
>> Patch for scheduler dependency lists.
>
> Looks like a pretty good cleanup IMHO. Here are some comments.
>
> o dep_def: representing a dependence edge including both producer and consumer
> is very handy, albeit somewhat redundant as we're usually traversing all cons
> connected to a pro or vice versa.
This allows us to keep all things in one place - one of the things
current deps don't provide. I.e., when changing some property of the
dep we need to find a corresponding to that dep nodes in both backward
and forward lists and apply the change to two places instead of one.
(I.e., has its pros and cons, but mostly pros
> I agree - also done in ddg.h/ddg_edge.) Maybe comment why both 'kind' and 'ds'
> are needed, as one supersedes the other.
There will be. Thanks.
>
> 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.
> 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.
>
> 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.
>
> o To add to the checking routines, the following can be checked: every
> dep_node_def is pointed-to by either its data->back xor its data->forw, right?
> If so, this can be used to identify if a dep_node_def is forward or backward;
> that all nodes on a list are forward (and share the same pro) or backward (and
> share the same con); and to assert the following regarding L:
> +/* Add a dependency described by DEP to the list L.
> + L should be either INSN_DEPS1 or RESOLVED_DEPS1. */
Good idea.
>
> o insn_cost (insn, dep): maybe it's better to break this into insn_cost (insn)
> of a producer regardless of consumers, and "dep_cost (dep)".
Agree.
>
> o The comment explaining what 'resolve_dep' does can be inlined together with
> its code.
Agree.
>
> +/* Detach dep_node N from the list. */
> +static void
> +dep_node_detach (dep_node_t n)
> +{
> + dep_node_t *prev_nextp = DEP_NODE_PREV_NEXTP (n);
> + dep_node_t next = DEP_NODE_NEXT (n);
> +
> + *prev_nextp = next;
> +
> + if (next != NULL)
> +DEP_NODE_PREV_NEXTP (next) = prev_nextp;
> maybe complete the detachment by adding:
> DEP_NODE_PREV_NEXTP (n) = NULL;
> DEP_NODE_NEXT (n) = NULL;
Probably, you are right.
> Ayal.
Thanks,
Maxim
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
