[Bug middle-end/48722] ICE in df_refs_verify() with -mno-push-args

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48722

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-08-22
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Jakub Jelinek  2011-08-22 
06:57:23 UTC ---
Created attachment 25072
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25072
gcc47-pr48722.patch

Untested fix.

[Bug fortran/50149] New: loader error with source containing common blocks

[riddle00 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149

 Bug #: 50149
   Summary: loader error with source containing common blocks
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: riddl...@gmail.com


Computer: MacBook Pro
 System Version:Mac OS X 10.6.8 (10K549)
  Kernel Version:Darwin 10.8.0

gcc/gfortran version 4.6.1

compiler options used when compiling:
-c -Wall -fbacktrace  -static-libgfortran -fcheck-array-temporaries \
 -finit-local-zero -fno-automatic -fbounds-check -pg -fpic -fpie

Error encountered: all modules compile as expected; however, if any two source
routines contain COMMON statement, I encounter the following error immediately
at load time:

ld: duplicate symbol ___BLNK__ in obj/trajectory.o and obj/integral.o
collect2: ld returned 1 exit status

removing COMMON statements from sources will eliminate this error and all is
good!

I would appreciate a reply if/when this problem is fixed and a new version is
available.  Thanks very much.

[Bug c/50142] There is bug when swap elements of an array via chain expression.

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50142

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2011-08-22 
06:06:29 UTC ---
You are wrong, please read the standard, in particular ISO C99 5.1.2.3 and
Annex C.

[Bug libfortran/50105] [4.6/4.7 Regression] I/O with g6.5 - wrong number of "**" shown

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50105

--- Comment #10 from Jerry DeLisle  2011-08-22 
03:37:30 UTC ---
I just returned from travel and will have a look at this.

[Bug bootstrap/50146] [4.7 regression] unused variable saved_nregs in ira-color.c broke arm-linux-gnueabi bootstrap

[vmakarov at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50146

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com

--- Comment #1 from Vladimir Makarov  2011-08-22 
03:32:18 UTC ---
(In reply to comment #0)
> gcc-4.7-20110820 fails to bootstrap on arm-linux-gnueabi with:
> 

> The issue is that saved_nregs is declared unconditionally but used #ifndef
> HONOR_REG_ALLOC_ORDER.  The ARM backend does define HONOR_REG_ALLOC_ORDER, so
> the warning is expected.
> 
> I'm testing the following fix:
> 
> --- gcc-4.7-20110820/gcc/ira-color.c.~1~2011-08-18 16:56:36.0
> +0200
> +++ gcc-4.7-20110820/gcc/ira-color.c2011-08-21 19:11:00.0 +0200
> @@ -1567,13 +1567,14 @@ static bool
>  assign_hard_reg (ira_allocno_t a, bool retry_p)
>  {
>HARD_REG_SET conflicting_regs[2], profitable_hard_regs[2];
> -  int i, j, hard_regno, best_hard_regno, class_size, saved_nregs;
> +  int i, j, hard_regno, best_hard_regno, class_size;
>int cost, mem_cost, min_cost, full_cost, min_full_cost, nwords, word;
>int *a_costs;
>enum reg_class aclass;
>enum machine_mode mode;
>static int costs[FIRST_PSEUDO_REGISTER], full_costs[FIRST_PSEUDO_REGISTER];
>  #ifndef HONOR_REG_ALLOC_ORDER
> +  int saved_nregs;
>enum reg_class rclass;
>int add_cost;
>  #endif

Sorry, my bad.  It is from my patch for PR50107.

The patch is ok so you can commit it to the trunk.

Thank you.

[Bug c/50142] There is bug when swap elements of an array via chain expression.

[thomas.c.zhao at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50142

--- Comment #2 from ZHAO Xiaogang  2011-08-22 
00:36:34 UTC ---
(In reply to comment #1)
> Evaluation order is undefined since there is no sequence point involved.

I don't think so.
The associativity of operator ^= is Right to Left.

I have build the code with other compiler.
gcc 3.x is OK.
Sun cc is OK.
Microsoft VC is OK.

If there isn't any array, it's also OK when use gcc4 build.
main()
{
 int a = 1, b = 2;
 a ^= b ^= a ^= b;
 printf("a=%d b=%d\n", a, b);
}

[expected result]: a=2 b=1
[actual result]: a=2 b=1

So, I guess, the defect associated with the gcc4 new feature which optimized
array access.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773

--- Comment #116 from Paolo Carlini  
2011-08-21 22:02:23 UTC ---
Thank you Rainer, and Marc, for the huge analysis and programming and testing
effort.

[Bug libstdc++/50143] Doxygen API documentation is invalid

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

--- Comment #15 from Paolo Carlini  2011-08-21 
21:48:14 UTC ---
If you can Jon, it would be great. I tried with the browsers I have at hand to
no avail, so far. Anyway, if trustworthy html validators report errors for the
pages generated by Doxygen, the developers should at least explain that (but
frankly, as I tried to explain already, I have no idea if those are really
serious or not and could explain serious visualization problems in some cases)

[Bug libstdc++/50143] Doxygen API documentation is invalid

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

--- Comment #14 from Jonathan Wakely  2011-08-21 
21:26:02 UTC ---
fine, I'll reproduce it and report a bug to Doxygen

[Bug fortran/49638] [OOP] length parameter is ignored when overriding type bound character functions with constant length.

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #22 from janus at gcc dot gnu.org 2011-08-21 21:15:09 UTC ---
I think we can close this one. Thanks for reporting, Hans-Werner.

[Bug bootstrap/50148] GCC fails to bootstrap with -O3 due to "may be used uninitialized" errors

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148

--- Comment #1 from Dmitry Gorbachev  
2011-08-21 21:12:23 UTC ---
Created attachment 25071
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25071
Patch for sched-deps.c

Also fails during -O3 LTO bootstrap in sched-deps.c.

(Another solution would be to build GCC with -Wno-error=maybe-uninitialized.)

[Bug bootstrap/50148] New: GCC fails to bootstrap with -O3 due to "may be used uninitialized" errors

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148

 Bug #: 50148
   Summary: GCC fails to bootstrap with -O3 due to "may be used
uninitialized" errors
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
  Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
 Build: i686-pc-linux-gnu


Created attachment 25070
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25070
Patch for c-parser.c

Error message:

../../gcc-4.7/gcc/c-parser.c: In function 'c_expr
c_parser_postfix_expression_after_primary(c_parser*, location_t, c_expr)':
../../gcc-4.7/gcc/c-parser.c:6664:16: error: 'origtypes' may be used
uninitialized in this function [-Werror=maybe-uninitialized]

[Bug libstdc++/50143] Doxygen API documentation is invalid

[giecrilj at stegny dot 2a.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

--- Comment #13 from Christopher Yeleighton  
2011-08-21 21:05:11 UTC ---
(In reply to comment #11)
> Doesn't happen here. Anyway, I still believe that a sensible way to go is
> filing a Bug Report with Doxygen. 

Apparently.  However, the problem is I cannot do it myself without isolating a
test case, and that requires reproducing the build, and that is I do not know
how to do.

[Bug libstdc++/50143] Doxygen API documentation is invalid

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

--- Comment #12 from Paolo Carlini  2011-08-21 
21:04:06 UTC ---
By the way, I just tried Safari 5.1 and it also works fine for me (as long as
the above link and a few others are concerned, at least)

[Bug libstdc++/50143] Doxygen API documentation is invalid

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

--- Comment #11 from Paolo Carlini  2011-08-21 
20:59:51 UTC ---
(In reply to comment #10)
> This is the same with Safari. Note that on both Safari and Firefox, I first 
> get
> a widow as displayed in the attachment in comment #5 then the right pane is
> redrawn in a legible way.

Doesn't happen here. Anyway, I still believe that a sensible way to go is
filing a Bug Report with Doxygen. In terms of Bug Reports. Or, make a
convincing case that another tool is **overall** preferable to Doxygen. I don't
think this kind of technical discussion really belongs here.

[Bug libstdc++/50143] Doxygen API documentation is invalid

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

--- Comment #10 from Dominique d'Humieres  
2011-08-21 20:56:00 UTC ---
> I don't know which browser you are using, but with Firefox 6 the documentation
> is definitely readable.

This is the same with Safari. Note that on both Safari and Firefox, I first get
a widow as displayed in the attachment in comment #5 then the right pane is
redrawn in a legible way.

[Bug libstdc++/50143] Doxygen API documentation is invalid

[giecrilj at stegny dot 2a.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

--- Comment #9 from Christopher Yeleighton  
2011-08-21 20:54:33 UTC ---
(In reply to comment #8)
> I don't know which browser you are using, but with Firefox 6 the documentation
> is definitely readable. 

Konqueror 4.6

> Also, I don't know if you are an HTML expert, I'm not,
> but I would not be **so** sure that all the visualization problems you are
> having are due to the html and not the browser and its rendering engine.

A browser bug against an invalid page will not be accepted.  It is undefined
behavior.

[Bug libstdc++/50143] Doxygen API documentation is invalid

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

--- Comment #8 from Paolo Carlini  2011-08-21 
20:50:06 UTC ---
I don't know which browser you are using, but with Firefox 6 the documentation
is definitely readable. Also, I don't know if you are an HTML expert, I'm not,
but I would not be **so** sure that all the visualization problems you are
having are due to the html and not the browser and its rendering engine.

[Bug libstdc++/50143] Doxygen API documentation is invalid

[giecrilj at stegny dot 2a.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

--- Comment #7 from Christopher Yeleighton  
2011-08-21 20:49:10 UTC ---
(In reply to comment #4)
> Bah, in my opinion, if Doxygen otherwise suits our needs we should just keep
> using it and ask users interested in HTML Validator results to file PR with
> Doxygen. But certainly I don't feel strongly about these issues.

The problem with this approach is that it is not easy for a user to reproduce
the problem, let alone isolate some test case.

[Bug c++/48875] Segmentation fault in maybe_clone_body with -fsyntax-only

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48875

--- Comment #3 from Dmitry Gorbachev  
2011-08-21 20:46:21 UTC ---
I can't reproduce it now.

[Bug libstdc++/50143] Doxygen API documentation is invalid

[giecrilj at stegny dot 2a.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

--- Comment #6 from Christopher Yeleighton  
2011-08-21 20:45:29 UTC ---
(In reply to comment #3)
> Of course building gcc isn't necessary to run doxygen.
> 

I unpacked gcc and I said { make make doc-html-doxygen; }.
Make said "No such target."

[Bug libstdc++/50143] Doxygen API documentation is invalid

[giecrilj at stegny dot 2a.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

--- Comment #5 from Christopher Yeleighton  
2011-08-21 20:41:56 UTC ---
Created attachment 25069
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25069
documentation screen shot

The documentation window contains two frames: the index frame and the content
frame.  The text in the content frame is obscured by the text in the index
frame even though the horizontal scrollbar in the content frame is in the
leftmost position (which is not immediately visible because of a bug in the
color scheme).  The documentation is unreadable.

[Bug lto/50147] New: LTO: Segmentation fault in infinite_empty_loop_p

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50147

 Bug #: 50147
   Summary: LTO: Segmentation fault in infinite_empty_loop_p
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
CC: rgue...@gcc.gnu.org
  Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
 Build: i686-pc-linux-gnu


Created attachment 25068
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25068
Backtrace

Testcase (extracted from libstdc++) is in attachment 25067.

Compile with GCC 4.7.0 with `-flto -O'. Also happens in GCC 4.6.2 with `-flto
-flto-partition=1to1 -O'.

[Bug lto/48259] Internal compiler errors in lto1

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48259

Dmitry Gorbachev  changed:

   What|Removed |Added

  Attachment #23782|0   |1
is obsolete||

--- Comment #9 from Dmitry Gorbachev  
2011-08-21 20:32:06 UTC ---
Created attachment 25067
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25067
Another testcase (extracted from libstdc++)

[Bug middle-end/50145] FAIL: gcc.dg/torture/pr50067-*.c -O* execution test on powerpc*-*-*

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50145

--- Comment #2 from Dominique d'Humieres  2011-08-21 
20:21:04 UTC ---
> Can you please check why?

Using (note that I am C illiterate;-)

  for (i = 0; i < 32; ++i)
printf("%hd  ", * (&a[i]));
  printf("\n");

before and after

  for (i = 0; i < 32; ++i)
(*((unsigned short(*)[32])&a[0]))[i] = (*((char(*)[32])&a[0]))[i+8];

I get on powerpc-apple-darwin9:

0  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21 
22  23  24  25  26  27  28  29  30  31  
0  4  0  5  0  6  0  7  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
 0  0  0  0  0  

instead of

0  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21 
22  23  24  25  26  27  28  29  30  31  
4  0  5  0  6  0  7  0  8  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
 0  0  0  0  0  

on x86_64-apple-darwin10.

[Bug libstdc++/50143] Doxygen API documentation is invalid

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

--- Comment #4 from Paolo Carlini  2011-08-21 
20:07:27 UTC ---
Bah, in my opinion, if Doxygen otherwise suits our needs we should just keep
using it and ask users interested in HTML Validator results to file PR with
Doxygen. But certainly I don't feel strongly about these issues.

[Bug libstdc++/50143] Doxygen API documentation is invalid

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

--- Comment #3 from Jonathan Wakely  2011-08-21 
19:54:15 UTC ---
(In reply to comment #2)
> Please tell me if you find the following argument invalid:
> 
>   1. 
> It is the responsibility of the library to provide API documentation for the
> developers using the library.

Yep

>   2. 
> The library can provide the documentation in whatever way it seems fit,
> provided that the documentation is readable and meets its essential purpose.

Yep.

>   3.
> The library documentation provided with the library is unreadable.

Utter nonsense.

> Conclusion: the library failed to provide appropriate documentation.  Ergo, it
> is the library‘s fault.  
> 
> The user is not interested in what particular tool the library manufacturer
> internally uses, as long as it works.  The user is not in position to tell
> whether the fault is in Doxygen markup or in Doxygen engine; in either case,
> the user is not in position to fix the documentation so as to make it useful.
> 
> If you feel that this is Doxygen‘s fault, you, as the manufacturer, have the
> following options:
> 
>   * 
> Diagnose the problem, file a bug at Doxygen and hope it will get fixed.
> 
>   * 
> Use some other tool to generate API documentation.
> 
>   * 
> Do nothing, and continue to ship a broken product pretending it is not your
> fault.
> 
> The choice is yours.  
> 
> I would be happy to be able to reproduce this Doxygen problem and isolate a
> reportable test case; however, I am not sure I know how to do it.  It seems
> building gcc first is necessary, and it is quite a job.

Of course building gcc isn't necessary to run doxygen.

This bug report is valid, but your argument is ridiculously overstated, let's
keep some sense of proportion.  The product being shipped is not "broken"
except in the most pedantic sense.

[Bug preprocessor/50144] cc1plus double free / out of bounds read

[edwintorok at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50144

Török Edwin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #4 from Török Edwin  2011-08-21 
19:48:34 UTC ---
Nevermind, just did a memtest and it found 1 stuck bit in one of the 4G
modules.
Going to close this as invalid for now, as I was not able to get any more
warnings with valgrind.

[Bug middle-end/50145] FAIL: gcc.dg/torture/pr50067-*.c -O* execution test on powerpc*-*-*

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50145

--- Comment #1 from Richard Guenther  2011-08-21 
19:37:26 UTC ---
Can you please check why?  I suppose it's a big/little-endian issue with the
testcase, so the expected array contents change?  Making the short input
array values duplicated in both bytes could fix the test (with adjusting
the expected output as well)

[Bug bootstrap/50146] [4.7 regression] unused variable saved_nregs in ira-color.c broke arm-linux-gnueabi bootstrap

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50146

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug libstdc++/50143] Doxygen API documentation is invalid

[giecrilj at stegny dot 2a.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

--- Comment #2 from Christopher Yeleighton  
2011-08-21 19:33:07 UTC ---
Please tell me if you find the following argument invalid:

  1. 
It is the responsibility of the library to provide API documentation for the
developers using the library.

  2. 
The library can provide the documentation in whatever way it seems fit,
provided that the documentation is readable and meets its essential purpose.

  3.
The library documentation provided with the library is unreadable.

Conclusion: the library failed to provide appropriate documentation.  Ergo, it
is the library‘s fault.  

The user is not interested in what particular tool the library manufacturer
internally uses, as long as it works.  The user is not in position to tell
whether the fault is in Doxygen markup or in Doxygen engine; in either case,
the user is not in position to fix the documentation so as to make it useful.

If you feel that this is Doxygen‘s fault, you, as the manufacturer, have the
following options:

  * 
Diagnose the problem, file a bug at Doxygen and hope it will get fixed.

  * 
Use some other tool to generate API documentation.

  * 
Do nothing, and continue to ship a broken product pretending it is not your
fault.

The choice is yours.  

I would be happy to be able to reproduce this Doxygen problem and isolate a
reportable test case; however, I am not sure I know how to do it.  It seems
building gcc first is necessary, and it is quite a job.

[Bug debug/49901] gfortran.dg/debug/[pr35154-dwarf2.f/pr37738.f] failures on darwin

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49901

--- Comment #8 from Dominique d'Humieres  2011-08-21 
18:08:39 UTC ---
Could the patch in comment #3 be applied without waiting for an answer about
what to do with the -gno-strict-dwarf option on strict-dwarf platforms?

[Bug tree-optimization/50133] [4.7 Regression] ICE: SIGSEGV in vect_finish_stmt_generation (gimple.h:4821) with -ftree-vectorize -fno-tree-loop-im

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50133

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-08-21 
17:43:08 UTC ---
Insert before gsi_end_p should be fine, you just can't copy locus from it in
that case.  So you could as well do something like:
  si = *gsi;
  if (gsi_end_p (si))
{
  gsi_prev (&si);
  gsi_prev_nondebug (&si);
}
  else if (is_gimple_debug (gsi_stmt (si)))
{
  gsi_next_nondebug (&si);
  gcc_assert (!gsi_end_p (si));
}

where the first gsi_prev would move from the end to the newly inserted stmt and
gsi_prev_nondebug to the previous stmt (skipping any debug stmts).
This wouldn't work when inserting into a completely empty bb, but does the
vectorizer ever do something like that?

[Bug bootstrap/50146] New: [4.7 regression] unused variable saved_nregs in ira-color.c broke arm-linux-gnueabi bootstrap

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50146

 Bug #: 50146
   Summary: [4.7 regression] unused variable saved_nregs in
ira-color.c broke arm-linux-gnueabi bootstrap
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@it.uu.se


gcc-4.7-20110820 fails to bootstrap on arm-linux-gnueabi with:

/mnt/scratch/objdir47/./prev-gcc/xgcc -B/mnt/scratch/objdir47/./prev-gcc/
-B/mnt/scratch/install47/armv5tel-brewer-linux-gnueabi/bin/
-B/mnt/scratch/install47/armv5tel-brewer-linux-gnueabi/bin/
-B/mnt/scratch/install47/armv5tel-brewer-linux-gnueabi/lib/ -isystem
/mnt/scratch/install47/armv5tel-brewer-linux-gnueabi/include -isystem
/mnt/scratch/install47/armv5tel-brewer-linux-gnueabi/sys-include-c   -g -O2
-gtoggle -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition
-Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I/mnt/scratch/gcc-4.7-20110820/gcc
-I/mnt/scratch/gcc-4.7-20110820/gcc/.
-I/mnt/scratch/gcc-4.7-20110820/gcc/../include
-I/mnt/scratch/gcc-4.7-20110820/gcc/../libcpp/include
-I/home/mikpe/pkgs/linux-armv5l/gmp-4.3.2/include
-I/home/mikpe/pkgs/linux-armv5l/mpfr-2.4.2/include
-I/home/mikpe/pkgs/linux-armv5l/mpc-0.8.2/include 
-I/mnt/scratch/gcc-4.7-20110820/gcc/../libdecnumber
-I/mnt/scratch/gcc-4.7-20110820/gcc/../libdecnumber/dpd -I../libdecnumber   
/mnt/scratch/gcc-4.7-20110820/gcc/ira-color.c -o ira-color.o
/mnt/scratch/gcc-4.7-20110820/gcc/ira-color.c: In function 'assign_hard_reg':
/mnt/scratch/gcc-4.7-20110820/gcc/ira-color.c:1570:54: error: unused variable
'saved_nregs' [-Werror=unused-variable]
cc1: all warnings being treated as errors

make[3]: *** [ira-color.o] Error 1
make[3]: Leaving directory `/mnt/scratch/objdir47/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/mnt/scratch/objdir47'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir47'
make: *** [bootstrap] Error 2

The previous weekly snapshot, gcc-4.7-20110813, bootstrapped fine.

The issue is that saved_nregs is declared unconditionally but used #ifndef
HONOR_REG_ALLOC_ORDER.  The ARM backend does define HONOR_REG_ALLOC_ORDER, so
the warning is expected.

I'm testing the following fix:

--- gcc-4.7-20110820/gcc/ira-color.c.~1~2011-08-18 16:56:36.0
+0200
+++ gcc-4.7-20110820/gcc/ira-color.c2011-08-21 19:11:00.0 +0200
@@ -1567,13 +1567,14 @@ static bool
 assign_hard_reg (ira_allocno_t a, bool retry_p)
 {
   HARD_REG_SET conflicting_regs[2], profitable_hard_regs[2];
-  int i, j, hard_regno, best_hard_regno, class_size, saved_nregs;
+  int i, j, hard_regno, best_hard_regno, class_size;
   int cost, mem_cost, min_cost, full_cost, min_full_cost, nwords, word;
   int *a_costs;
   enum reg_class aclass;
   enum machine_mode mode;
   static int costs[FIRST_PSEUDO_REGISTER], full_costs[FIRST_PSEUDO_REGISTER];
 #ifndef HONOR_REG_ALLOC_ORDER
+  int saved_nregs;
   enum reg_class rclass;
   int add_cost;
 #endif

[Bug preprocessor/50144] cc1plus double free / out of bounds read

[edwintorok at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50144

--- Comment #3 from Török Edwin  2011-08-21 
16:41:19 UTC ---
(In reply to comment #2)
> The valgrind errors about search_line_sse2 are valgrind bugs rather than gcc
> bugs.  Just ignore them.

OK, I'll try to find some other valgrind trace.

(In reply to comment #0)
> CXXMemoryBuiltins.lo
> *** glibc detected ***
> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus: double free or
> corruption (out): 0x02a0e280 ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6[0x3c71472606]
> /lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x3c7147733c]
> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(ggc_internal_alloc_stat+0x25e)[0x5bb86e]
> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(ggc_internal_cleared_alloc_stat+0x16)[0x6c1446]
> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(make_node_stat+0x1f)[0x8e1fff]
> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(alloc_stmt_list+0x5a)[0x8059ca]
> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(push_stmt_list+0x6)[0x5b47f6]
> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus[0x550e25]
> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(begin_if_stmt+0x15)[0x551765]

begin_if_stmt appears to be part of the parser though, not the preprocessor
(I thought if refers to #if, but apparently not). So was this a parser crash?

[Bug fortran/47659] -Wconversion[-extra] should emit warning for constant expressions

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47659

--- Comment #6 from Thomas Koenig  2011-08-21 
16:35:31 UTC ---
Author: tkoenig
Date: Sun Aug 21 16:35:28 2011
New Revision: 177942

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177942
Log:
2011-08-21  Thomas Koenig  

PR fortran/47659
* expr.c (gfc_check_assign): Check for type conversions when the
right-hand side is a constant REAL/COMPLEX contstant the left-hand
side is also REAL/COMPLEX.  Don't warn when a narrowing conversion
for REAL does not change the value of the constant.

2011-08-21  Thomas Koenig  

PR fortran/47659
* gfortran.dg/warn_conversion_2.f90:  Also warn about conversion
of a constant resulting from simplification.
* gfortran.dg/warn_conversion_3.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/warn_conversion_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/warn_conversion_2.f90

[Bug preprocessor/50144] cc1plus double free / out of bounds read

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50144

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-08-21 
16:12:50 UTC ---
The valgrind errors about search_line_sse2 are valgrind bugs rather than gcc
bugs.  Just ignore them.

[Bug preprocessor/50144] cc1plus double free / out of bounds read

[edwintorok at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50144

--- Comment #1 from Török Edwin  2011-08-21 
15:52:33 UTC ---
And here is a stacktrace from a local GCC build so you have line numbers:
$ valgrind --trace-children=yes
/home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/xgcc
-B/home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc /tmp/x.cpp -E
>/dev/null
==2671== Memcheck, a memory error detector
==2671== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==2671== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==2671== Command: /home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/xgcc
-B/home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc /tmp/x.cpp -E
==2671== 
==2675== Memcheck, a memory error detector
==2675== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==2675== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==2675== Command:
/home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/cc1plus -E -quiet
-iprefix
/home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/../lib/gcc/x86_64-linux-gnu/4.6.1/
-isystem /home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/include
-isystem /home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/include-fixed
-D_GNU_SOURCE /tmp/x.cpp -mtune=generic -march=x86-64
==2675== 
==2675== Invalid read of size 8
==2675==at 0x11D71C9: search_line_sse2 (lex.c:394)
==2675==by 0x11D7361: _cpp_clean_line (lex.c:666)
==2675==by 0x11D7D37: _cpp_get_fresh_line (lex.c:1887)
==2675==by 0x11D94B1: _cpp_lex_direct (lex.c:1952)
==2675==by 0x11DA2F6: _cpp_lex_token (lex.c:1826)
==2675==by 0x11DC9F7: cpp_get_token (macro.c:1240)
==2675==by 0x11DCC8F: cpp_get_token_with_location (macro.c:1352)
==2675==by 0x6C87A4: preprocess_file (c-ppoutput.c:175)
==2675==by 0x6C6D2B: c_common_init (c-opts.c:1057)
==2675==by 0x5C7668: cxx_init (lex.c:254)
==2675==by 0xA3204C: toplev_main (toplev.c:1742)
==2675==by 0x3C7141EEAC: (below main) (libc-start.c:228)
==2675==  Address 0x4cec1f0 is 7,232 bytes inside a block of size 7,238 alloc'd
==2675==at 0x4A07882: realloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2675==by 0x120070C: xrealloc (xmalloc.c:179)
==2675==by 0x11CC03B: _cpp_convert_input (charset.c:1734)
==2675==by 0x11D4962: read_file (files.c:648)
==2675==by 0x11D535A: _cpp_stack_file (files.c:723)
==2675==by 0x11D6C35: cpp_read_main_file (init.c:570)
==2675==by 0x6C64EA: c_common_post_options (c-opts.c:1016)
==2675==by 0xA31B30: toplev_main (toplev.c:1283)
==2675==by 0x3C7141EEAC: (below main) (libc-start.c:228)
==2675== 
==2675== Invalid read of size 8
==2675==at 0x11D71B3: search_line_sse2 (lex.c:382)
==2675==by 0x11D7361: _cpp_clean_line (lex.c:666)
==2675==by 0x11D7D37: _cpp_get_fresh_line (lex.c:1887)
==2675==by 0x11D94B1: _cpp_lex_direct (lex.c:1952)
==2675==by 0x11DA2F6: _cpp_lex_token (lex.c:1826)
==2675==by 0x11DC9F7: cpp_get_token (macro.c:1240)
==2675==by 0x11DCC8F: cpp_get_token_with_location (macro.c:1352)
==2675==by 0x6C87A4: preprocess_file (c-ppoutput.c:175)
==2675==by 0x6C6D2B: c_common_init (c-opts.c:1057)
==2675==by 0x5C7668: cxx_init (lex.c:254)
==2675==by 0xA3204C: toplev_main (toplev.c:1742)
==2675==by 0x3C7141EEAC: (below main) (libc-start.c:228)
==2675==  Address 0x4cec1f0 is 7,232 bytes inside a block of size 7,238 alloc'd
==2675==at 0x4A07882: realloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2675==by 0x120070C: xrealloc (xmalloc.c:179)
==2675==by 0x11CC03B: _cpp_convert_input (charset.c:1734)
==2675==by 0x11D4962: read_file (files.c:648)
==2675==by 0x11D535A: _cpp_stack_file (files.c:723)
==2675==by 0x11D6C35: cpp_read_main_file (init.c:570)
==2675==by 0x6C64EA: c_common_post_options (c-opts.c:1016)
==2675==by 0xA31B30: toplev_main (toplev.c:1283)
==2675==by 0x3C7141EEAC: (below main) (libc-start.c:228)

[Bug lto/49677] GCC 4.6.0 LTO files not compatible with GCC 4.6.1

[xunxun1982 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49677

PcX  changed:

   What|Removed |Added

 CC||xunxun1982 at gmail dot com

--- Comment #1 from PcX  2011-08-21 15:33:07 UTC 
---
I can confirm the error.
And I found that, if I update to a newer gcc, for example, gcc 4.6.2
(20110819), their LTO information will be not compatible.
It also will cause the errors : 
lto1: error: bad value (generic) for -mtls-dialect= switch
lto-wrapper: /usr/bin/gcc returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status

In the end, I must recompile it using the newer gcc with LTO.

[Bug middle-end/50145] New: FAIL: gcc.dg/torture/pr50067-*.c -O* execution test on powerpc*-*-*

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50145

 Bug #: 50145
   Summary: FAIL: gcc.dg/torture/pr50067-*.c -O* execution test on
powerpc*-*-*
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: rguent...@suse.de
  Host: powerpc*-*-*
Target: powerpc*-*-*
 Build: powerpc*-*-*


gcc.dg/torture/pr50067-*.c aborts on powerpc*-*-* (see
http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg02191.html and
http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg02189.html). AFAICT this is
not a regression: they aborts also when compiled with gcc 4.4.6.

[Bug lto/49844] Building CodeBlocks on Windows using mingw gcc 4.6.1 "-flto -fuse-linker-plugin" results in many linker stage errors

[xunxun1982 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49844

--- Comment #6 from PcX  2011-08-21 15:28:43 UTC 
---
I update to gcc 4.6.2 (20110819) and binutils 2.21.53.20110820, and it also has
the problem.

[Bug preprocessor/50144] New: cc1plus double free / out of bounds read

[edwintorok at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50144

 Bug #: 50144
   Summary: cc1plus double free / out of bounds read
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: edwinto...@gmail.com


Created attachment 25066
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25066
x.cpp

Lately gcc 4.6.1 has been segfaulting quite often. Not always on the same file,
but usually when building ClamAV in 'make distcheck' mode.

See below for a double free stacktrace.
Running valgrind on the preprocessed file doesn't show anything, but running
valgrind on original GCC invocation shows some errors in the preprocessor.

Here is a command that reproduces the valgrind error. 
$ valgrind /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus -quiet
x.cpp -E >/dev/null

The file x.cpp is attached, and has all #include removed and still shows the
valgrind error:
==3237== Invalid read of size 8
==3237==at 0xBFEFE9: ??? (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xBFF181: _cpp_clean_line (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xBFFB57: _cpp_get_fresh_line (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xC012D1: _cpp_lex_direct (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xC02116: _cpp_lex_token (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xC04817: cpp_get_token (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xC04AAF: cpp_get_token_with_location (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0x5AE914: preprocess_file (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0x5ACF1A: c_common_init (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0x513228: cxx_init (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0x7D40AC: toplev_main (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0x3C7141EEAC: (below main) (libc-start.c:228)
==3237==  Address 0x4ceb0c0 is 7,232 bytes inside a block of size 7,238 alloc'd
==3237==at 0x4A07882: realloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3237==by 0xC2865C: xrealloc (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xBF3E5B: _cpp_convert_input (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xBFC782: ??? (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xBFD17A: _cpp_stack_file (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xBFEA55: cpp_read_main_file (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0x5AC72A: c_common_post_options (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0x7D3BA2: toplev_main (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0x3C7141EEAC: (below main) (libc-start.c:228)
==3237== 
==3237== Invalid read of size 8
==3237==at 0xBFEFD3: ??? (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xBFF181: _cpp_clean_line (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xBFFB57: _cpp_get_fresh_line (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xC012D1: _cpp_lex_direct (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xC02116: _cpp_lex_token (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xC04817: cpp_get_token (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xC04AAF: cpp_get_token_with_location (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0x5AE914: preprocess_file (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0x5ACF1A: c_common_init (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0x513228: cxx_init (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0x7D40AC: toplev_main (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0x3C7141EEAC: (below main) (libc-start.c:228)
==3237==  Address 0x4ceb0c0 is 7,232 bytes inside a block of size 7,238 alloc'd
==3237==at 0x4A07882: realloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3237==by 0xC2865C: xrealloc (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xBF3E5B: _cpp_convert_input (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
==3237==by 0xBFC782: ??? (in
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus

[Bug libstdc++/50143] Doxygen API documentation is invalid

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

--- Comment #1 from Paolo Carlini  2011-08-21 
15:03:38 UTC ---
And the page has been *generated* by Doxygen (1.7.4, in particular), right? So,
why do you think that, if anything, this is a libstdc++ bug?!?

[Bug libstdc++/50143] New: Doxygen API documentation is invalid

[giecrilj at stegny dot 2a.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143

 Bug #: 50143
   Summary: Doxygen API documentation is invalid
Classification: Unclassified
   Product: gcc
   Version: 4.5.1
   URL: http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen
/a01566.html
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: giecr...@stegny.2a.pl


Submit that page to the WWW HTML validator, and the result is:

Validation Output: 5819 Errors
Line 63, Column 4: document type does not allow element "li" here; missing one
of "ul", "ol", "menu", "dir" start-tag

(and 5818 errors follow)

Wow!

[Bug fortran/50130] [4.6/4.7 Regression] ICE with invalid array slice

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50130

--- Comment #5 from Thomas Koenig  2011-08-21 
12:02:16 UTC ---
Author: tkoenig
Date: Sun Aug 21 12:02:12 2011
New Revision: 177940

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177940
Log:
2011-08-21  Thomas Koenig  

PR fortran/50130
* resolve.c (resolve_array_ref):  Don't calculate upper bound
if the stride is zero.

2011-08-21  Thomas Koenig  

PR fortran/50130
* gfortran.dg/zero_stride_1.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/zero_stride_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug target/50135] Loop optimization.

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50135

--- Comment #3 from Jan Hubicka  2011-08-21 12:01:20 UTC 
---
> I bet we have a duplicate report for not using the x86 loop instruction.
Well, we used to generate it until we concluded it is pointless...

Honza

Re: [Bug target/50135] Loop optimization.

[Jan Hubicka]

> I bet we have a duplicate report for not using the x86 loop instruction.
Well, we used to generate it until we concluded it is pointless...

Honza

[Bug c/50142] There is bug when swap elements of an array via chain expression.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50142

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-08-21 
11:54:44 UTC ---
Evaluation order is undefined since there is no sequence point involved.

[Bug fortran/50130] [4.6/4.7 Regression] ICE with invalid array slice

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50130

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |tkoenig at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Thomas Koenig  2011-08-21 
11:37:45 UTC ---
This one should be easy enough.

[Bug c/50142] New: There is bug when swap elements of an array via chain expression.

[thomas.c.zhao at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50142

 Bug #: 50142
   Summary: There is bug when swap elements of an array via chain
expression.
Classification: Unclassified
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thomas.c.z...@gmail.com


[gcc version]: 4.0.3
[system type]: sparc-sun-solaris2.10
[build options]: none
[source code]:
main()
{
 int a[] = {1,2};
 a[0] ^= a[1] ^= a[0] ^= a[1];
 printf("a[0]=%d a[1]=%d\n", a[0], a[1]);
}

[expected result]: a[0]=2 a[1]=1
[actual result]: a[0]=0 a[1]=1

btw: gcc3 is ok.

[Bug bootstrap/50139] in-tree GMP/PPL/CLooG is misconfigured

[vanboxem.ruben at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139

--- Comment #2 from Ruben Van Boxem  
2011-08-21 10:48:32 UTC ---
Created attachment 25065
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25065
Patch for 4.6 branch

Attached congruent patch for 4.6 branch.

[Bug bootstrap/50139] in-tree GMP/PPL/CLooG is misconfigured

[vanboxem.ruben at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139

--- Comment #1 from Ruben Van Boxem  
2011-08-21 10:47:56 UTC ---
Created attachment 25064
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25064
patch for 4.5 branch

Attached congruent patch for 4.5 branch

[Bug target/50135] Loop optimization.

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50135

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2011-08-21
 Ever Confirmed|0   |1

--- Comment #2 from Uros Bizjak  2011-08-21 10:25:31 
UTC ---
Don't worry about loop insn, it is *SLOW* on every half-decent recent
processor, see instruction_tables.pdf at [1]. OTOH, the insn has only short
jump displacement, so you are out of luck for every loop larger than 128 bytes.

So, until x86 implements something like powerpc bdnz insn, there will be no
doloop_* patterns.

[1] http://agner.org/optimize/

[Bug middle-end/50137] [4.7 Regression] ppc64/libstdc++-v3 is miscompiled on powerpc-apple-darwin9 since revision 177691

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50137

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug tree-optimization/50138] [4.6 Regression] ICE in vect_transform_stmt

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50138

Richard Guenther  changed:

   What|Removed |Added

 CC||irar at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |4.6.2
Summary|ICE in vect_transform_stmt  |[4.6 Regression] ICE in
   ||vect_transform_stmt

[Bug bootstrap/50010] [4.7 regression] i386-unknown-freebsd bootstrap comparison failure

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug target/50135] Loop optimization.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50135

Richard Guenther  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
  Component|c   |target

--- Comment #1 from Richard Guenther  2011-08-21 
09:20:40 UTC ---
I bet we have a duplicate report for not using the x86 loop instruction.

[Bug c/50136] Loop inc/dec optimization.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50136

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #1 from Richard Guenther  2011-08-21 
09:20:05 UTC ---
inc/dec is chosen if you compile for selected CPUs where this is the
faster variant.

[Bug target/50131] Optimize x = -1 with "or" for -O

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50131

--- Comment #4 from Richard Guenther  2011-08-21 
09:19:28 UTC ---
I'm sure or $-1,reg doesn't avoid the data dependence on reg and may even
result in hitting partial reg stall issues.  Surely xor reg,reg; not reg
might be another alternative?

[Bug c/50141] New: ICE: tree check: expected var_decl, have parm_decl in get_bit_range, at expr.c:4357 with --param allow-store-data-races=0 and bitfields

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50141

 Bug #: 50141
   Summary: ICE: tree check: expected var_decl, have parm_decl in
get_bit_range, at expr.c:4357 with --param
allow-store-data-races=0 and bitfields
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: al...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 25063
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25063
reduced testcase

Compiler output:
$ gcc --param allow-store-data-races=0 testcase.c
testcase.c: In function 'foo':
testcase.c:11:7: internal compiler error: tree check: expected var_decl, have
parm_decl in get_bit_range, at expr.c:4357
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The same happens when compiled as C++.

[Bug tree-optimization/50133] [4.7 Regression] ICE: SIGSEGV in vect_finish_stmt_generation (gimple.h:4821) with -ftree-vectorize -fno-tree-loop-im

[irar at il dot ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50133

Ira Rosen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-21
 Ever Confirmed|0   |1

[Bug tree-optimization/50133] [4.7 Regression] ICE: SIGSEGV in vect_finish_stmt_generation (gimple.h:4821) with -ftree-vectorize -fno-tree-loop-im

[irar at il dot ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50133

Ira Rosen  changed:

   What|Removed |Added

 CC||irar at il dot ibm.com

--- Comment #1 from Ira Rosen  2011-08-21 06:02:10 UTC 
---
When creating a vector from an invariant scalar load, we do 
gsi_next (&gsi2); 
in order to insert the vector after the load. In this testcase the load is the
last stmt in its basic block, which causes the failure when we try to call
gsi_stmt().

This patch fixes the failure:
Index: tree-vect-stmts.c
===
--- tree-vect-stmts.c   (revision 177929)
+++ tree-vect-stmts.c   (working copy)
@@ -1435,6 +1435,9 @@ vect_finish_stmt_generation (gimple stmt, gimple v
 }

   si = *gsi;
+  if (gsi_end_p (si))
+si = gsi_for_stmt (stmt);
+
   if (is_gimple_debug (gsi_stmt (si)))
 {
   gsi_next_nondebug (&si);

but it's a hack.

We could add a new parameter insert_after to vect_finish_stmt_generation (), to
indicate that VECT_STMT should be inserted after GSI and not before. For this
case we would have to pass it to vect_init_vector() first.

Ira