[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[jpr at csc dot fi]

--- Comment #27 from jpr at csc dot fi  2008-02-14 08:12 ---

I think that the test program shown in comment #25 is invalid, as the main
program does not know about the call interface of the check_integer4_rank1()
function. If you add the module related lines in the comments, all is well (at
least on a i686-linux machine).


-- 


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

[Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.

[dannysmith at users dot sourceforge dot net]

--- Comment #5 from dannysmith at users dot sourceforge dot net  2008-02-14 
08:14 ---
And just think of the havoc that will be caused with old mingw32 and cygwin
libs that depend on the _chkstk meaning of __alloca if you change __alloca
semantics.
eg there are 69 undefined references to __alloca in  mingw32-gcc-4.2.1 built
libgmp.a 

In my opinion it is a bug that 64 bit mingw defines __alloca differently to 32
bit mingw.  


Danny



-- 


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

[Bug c++/35159] g++ inoperable with no error message

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-02-14 08:15 ---
It would be helpful if you could post the actual errors that are reported for
the ICE, perhaps backtrace and other details.  Guess most of the people don't
have access to this target and I doubt it can be reproduced using a cross
compiler.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.

[ktietz at gcc dot gnu dot org]

--- Comment #6 from ktietz at gcc dot gnu dot org  2008-02-14 09:00 ---
I agree, that the havoc for 32-bit backward compatibility is to avoid.
But the havoc for windows sources using -fno-builtin and using _alloca () for
stack allocation produces in future even more troubles IMHO.

We allready defined the macro _alloca as 32-bit mingw does. The next source
tarball will inherit this patch.

But if we simply add a return type in eax for 32-bit world, does this really
harm anybody?


-- 


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

[Bug c++/35159] g++ inoperable with no error message

[ktietz at gcc dot gnu dot org]

--- Comment #6 from ktietz at gcc dot gnu dot org  2008-02-14 09:07 ---
Hello,

I tracked the problems down. Stack probing in builtin_alloca is the reason for
this. As I found, in some cases the input %rax argument isn't got set at all or
got clobbered before call to __chkstk.
The work-a-round for this, is to disable stack probing. So I assume the reason
is to be searched in optimization or in the builtin function itself.
AFAICS the implementation in the i386.md file seems to be ok.

Cheers, Kai


-- 


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

[Bug fortran/35154] Unable to reference symbols in Fortran COMMON due to .stabs format

[george at gcc dot gnu dot org]

-- 

george at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |george at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-14 09:09:32
   date||


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

[Bug tree-optimization/34864] array constants after inlining and "staticification"

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-02-14 09:13 ---
It's probably still the same issue - in initializers we only fold builtin
functions, where the std:: variants are not recognized as such (they are
wrapper functions around the builtin).  So this gets folded only after
inlining those, but then the initializer is already no longer marked as
constant, but initialized at runtime (with constants).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug c++/35159] g++ inoperable with no error message

[ubizjak at gmail dot com]

--- Comment #7 from ubizjak at gmail dot com  2008-02-14 09:19 ---
Just a shoot-in-the-dark question... does allocate_stack_worker_64 needs +a, as
is the case in allocate_stack_worker_32 ?


-- 


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

[Bug c++/35159] g++ inoperable with no error message

[ktietz at gcc dot gnu dot org]

--- Comment #8 from ktietz at gcc dot gnu dot org  2008-02-14 09:26 ---
I tested this already and it didn't solved the problem. But may +a is more
correct.

Cheers, Kai


-- 


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

[Bug c++/35159] g++ inoperable with no error message

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-02-14 09:32 ---
x86_64-mingw is neither a primary nor a secondary target, also this PR is not
a regression as this target is new.  So this clearly should not be P1 (though
technically it doesn't matter as this PR isn't a regression anyway).


-- 


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

[Bug c++/35159] g++ inoperable with no error message

[ubizjak at gmail dot com]

--- Comment #10 from ubizjak at gmail dot com  2008-02-14 09:38 ---
(In reply to comment #8)
> I tested this already and it didn't solved the problem. But may +a is more
> correct.

Perhaps setting RTX_FRAME_RELATED_P is needed? Or gen_blockage() at some point?


-- 


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

[Bug middle-end/35188] Missing a warning: if-condition is inherently blocking the if-body

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-02-14 09:48 ---
Also please produce a complete compilable testcase.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

--- Comment #29 from ubizjak at gmail dot com  2008-02-14 09:58 ---
(In reply to comment #28)
> With darwin bootstraps and regtest removal of the defines in
> cc/config/i386/darwin.h

Hm... I assume you did recompile libgfortran and libstdc++...


-- 


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

[Bug tree-optimization/34864] array constants after inlining and "staticification"

[tbptbp at gmail dot com]

--- Comment #4 from tbptbp at gmail dot com  2008-02-14 10:02 ---
Hmm. If i correctly understand what you're saying, *cough*, ldexp should be
immune to this missed-folding-because-a-builtin-isn't-recognized-as-such; but
in the original code that lead to PR34774 there's nothing but ldexp, yet *some*
of them occur at runtime under some weird conditions.
Of course i'd prefer to use a properly typed ldexp better than hope the
compiler realize it's about mere floats and not doubles, but that would be the
icing on the cake :)


-- 


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

[Bug c++/35159] g++ inoperable with no error message

[ktietz at gcc dot gnu dot org]

--- Comment #11 from ktietz at gcc dot gnu dot org  2008-02-14 10:03 ---
May I find a point, where things aren't treated for 64-bit correctly for
Windows. In i386.c ix86_expand_prologue() there are stack pointer manipulation
operations using 4 byte offset for both targets (32 and 64). I am currently
rebuild and test.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[dominiq at lps dot ens dot fr]

--- Comment #30 from dominiq at lps dot ens dot fr  2008-02-14 10:09 ---
> Hm... I assume you did recompile libgfortran and libstdc++...

In comment #25 I have said:

> I bootstraped without the defines

Anyway, even if the change had solved the problem, I would not have considered
it as a long term fix.
I do not know the technicalities around the *STACK_BOUNDARY stuff to
participate to the discussion, but I think this PR only expose an underlying
bug that should be analyzed.

>From what I understand, if *STACK_BOUNDARY is larger than the size of what is
pushed in the stack, some padding is performed. So the basic question is why
this done for -O2 and not for -Os.

I am currently regtesting libstdc++-v3 rev. 132313, with the defines to confirm
that the failures has not been induced by something else.


-- 


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

[Bug c++/35182] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-14 09:41 ---
With 4.3 and checking enabled I get

/usr/include/c++/4.3/tr1_impl/boost_shared_ptr.h: In member function 'void
std::tr1::__shared_ptr<_Tp, _Lp>::reset(_Tp1*) [with _Tp1 = int, _Tp = int,
__gnu_cxx::_Lock_policy _Lp = _S_atomic]':
/usr/include/c++/4.3/tr1_impl/boost_shared_ptr.h:441: internal compiler error:
in get_addr_dereference_operands, at tree-ssa-operands.c:1698
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

so maybe this is related to PR34989.  I can confirm that 4.2 and 4.3 ICE and
that 4.1 is fine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code
  Known to fail||4.2.3 4.3.0
  Known to work||4.1.2
Summary|ICE in  |[4.2/4.3 Regression] ICE in
   |coalesce_abnormal_edges |coalesce_abnormal_edges
   Target Milestone|--- |4.2.4


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

[Bug c++/35183] ice for illegal code

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-14 09:44 ---
Alphabet/AlphIO.cpp:361: error: void value not ignored as it ought to be

so, this is not legal code.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||error-recovery, ice-
   ||checking, ice-on-invalid-
   ||code
Summary|ice for legal code  |ice for illegal code


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

[Bug rtl-optimization/35190] Wrong branch instruction with -freorder-blocks-and-partition on SH

[steven at gcc dot gnu dot org]

--- Comment #1 from steven at gcc dot gnu dot org  2008-02-14 10:10 ---
At least add a comment please why REG_CROSSING would need special treatment.


-- 


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

[Bug c++/35182] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2008-02-14 10:12 ---
ICE on valid code should be P1.


-- 


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

[Bug c++/35182] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-14 10:13:20
   date||


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[dominiq at lps dot ens dot fr]

--- Comment #28 from dominiq at lps dot ens dot fr  2008-02-14 09:46 ---
With darwin bootstraps and regtest removal of the defines in
cc/config/i386/darwin.h

I have the following for gfortran:

FAIL: gfortran.dg/c_f_pointer_tests.f90  -O0  execution test
FAIL: gfortran.dg/c_f_pointer_tests.f90  -O1  execution test
FAIL: gfortran.dg/c_f_pointer_tests.f90  -O2  execution test
FAIL: gfortran.dg/c_f_pointer_tests.f90  -O3 -fomit-frame-pointer  execution
test
FAIL: gfortran.dg/c_f_pointer_tests.f90  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/c_f_pointer_tests.f90  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/c_f_pointer_tests.f90  -O3 -g  execution test
FAIL: gfortran.dg/c_f_pointer_tests.f90  -Os  execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -O0  execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -O1  execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -O2  execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -O3 -g  execution test
FAIL: gfortran.dg/c_ptr_tests.f03  -Os  execution test

These tests pass with the defines.

I see also numerous failures in libstdc++ :

=== libstdc++ tests ===


Running target unix
XPASS: 21_strings/basic_string/element_access/char/21674.cc execution test
XPASS: 21_strings/basic_string/element_access/wchar_t/21674.cc execution test
FAIL: 23_containers/bitset/invalidation/1.cc execution test
FAIL: 23_containers/deque/invalidation/1.cc execution test
FAIL: 23_containers/deque/invalidation/2.cc execution test
FAIL: 23_containers/deque/invalidation/3.cc execution test
FAIL: 23_containers/deque/invalidation/4.cc execution test
FAIL: 23_containers/list/invalidation/1.cc execution test
FAIL: 23_containers/list/invalidation/2.cc execution test
FAIL: 23_containers/list/invalidation/3.cc execution test
FAIL: 23_containers/list/invalidation/4.cc execution test
FAIL: 23_containers/map/invalidation/1.cc execution test
FAIL: 23_containers/map/invalidation/2.cc execution test
FAIL: 23_containers/map/modifiers/insert/16813.cc execution test
FAIL: 23_containers/multimap/invalidation/1.cc execution test
FAIL: 23_containers/multimap/invalidation/2.cc execution test
FAIL: 23_containers/multiset/invalidation/1.cc execution test
FAIL: 23_containers/multiset/invalidation/2.cc execution test
FAIL: 23_containers/set/invalidation/1.cc execution test
FAIL: 23_containers/set/invalidation/2.cc execution test
FAIL: 23_containers/vector/invalidation/1.cc execution test
FAIL: 23_containers/vector/invalidation/2.cc execution test
FAIL: 23_containers/vector/invalidation/3.cc execution test
FAIL: 23_containers/vector/invalidation/4.cc execution test
XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for
excess errors)
FAIL: ext/mt_allocator/deallocate_local_thread-5.cc execution test
FAIL: ext/mt_allocator/deallocate_local_thread-7.cc execution test

=== libstdc++ Summary for unix ===

# of expected passes4934
# of unexpected failures24
# of unexpected successes   3
# of expected failures  59
# of unsupported tests  328

Running target unix/-m64
FAIL: 21_strings/basic_string/cons/char/6.cc execution test
FAIL: 21_strings/basic_string/cons/wchar_t/6.cc execution test
XPASS: 21_strings/basic_string/element_access/char/21674.cc execution test
XPASS: 21_strings/basic_string/element_access/wchar_t/21674.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/char/1.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/char/6.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/char/7.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/char/8.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/wchar_t/1.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/wchar_t/6.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/wchar_t/7.cc execution test
FAIL: 21_strings/basic_string/inserters_extractors/wchar_t/8.cc execution test
FAIL: 22_locale/money_get/get/char/14.cc execution test
FAIL: 22_locale/money_get/get/char/22131.cc execution test
FAIL: 22_locale/money_get/get/char/6.cc execution test
FAIL: 22_locale/money_get/get/char/7.cc execution test
FAIL: 22_locale/money_get/get/char/8.cc execution test
FAIL: 22_locale/money_get/get/char/9.cc execution test
FAIL: 22_locale/money_get/get/wchar_t/14.cc execution test
FAIL: 22_locale/money_get/get/wchar_t/22131.cc execution test
FAIL: 22_locale/money_get/get/wchar_t/6.cc execution test
FAIL: 22_locale/money_get/get/wchar_t/7.cc execution test
FAIL: 22_locale/money_get/get/wchar_t/8.cc execution test
FAIL: 22_locale/m

[Bug tree-optimization/34864] array constants after inlining and "staticification"

[rguenther at suse dot de]

--- Comment #5 from rguenther at suse dot de  2008-02-14 10:14 ---
Subject: Re:  array constants after inlining
 and "staticification"

On Thu, 14 Feb 2008, tbptbp at gmail dot com wrote:

> --- Comment #4 from tbptbp at gmail dot com  2008-02-14 10:02 ---
> Hmm. If i correctly understand what you're saying, *cough*, ldexp should be
> immune to this missed-folding-because-a-builtin-isn't-recognized-as-such; but

yes

> in the original code that lead to PR34774 there's nothing but ldexp, yet 
> *some*
> of them occur at runtime under some weird conditions.

I'd like to see a testcase for this as this would be a bug ;)

Richard.


-- 


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

[Bug c++/35182] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges

[rguenther at suse dot de]

--- Comment #3 from rguenther at suse dot de  2008-02-14 10:14 ---
Subject: Re:  [4.2/4.3 Regression] ICE in coalesce_abnormal_edges

On Thu, 14 Feb 2008, steven at gcc dot gnu dot org wrote:

> --- Comment #2 from steven at gcc dot gnu dot org  2008-02-14 10:12 
> ---
> ICE on valid code should be P1.

Uh, not in general ;)  But at least we need a reduced testcase first.


-- 


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

[Bug tree-optimization/34864] array constants after inlining and "staticification"

[tbptbp at gmail dot com]

--- Comment #6 from tbptbp at gmail dot com  2008-02-14 10:30 ---
Well, this was my best attempt so far at cornering that issue. I'm gonna wave a
dead chicken and try another attack vector. Sigh.


-- 


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

[Bug target/34930] [4.3 Regression] ICE in instantiate_virtual_regs_in_insn with vector splat load

[dominiq at lps dot ens dot fr]

--- Comment #12 from dominiq at lps dot ens dot fr  2008-02-14 10:36 ---
With the patch in comment #10, the ICE is fixed and I did not see any obvious
regression in 32 bit mode and gfortran 64 bit mode.


-- 


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

[Bug c++/34937] [4.1/4.2 regression] ICE with attribute weak

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-02-14 10:48 ---
Subject: Bug 34962

Author: jason
Date: Wed Feb 13 21:27:16 2008
New Revision: 132297

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132297
Log:
PR c++/34962, c++/34937, c++/34939
* decl2.c (is_late_template_attribute): Always defer attributes
vector_size and weak.

Added:
trunk/gcc/testsuite/g++.dg/ext/tmplattr9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE
   |with attribute weak |with attribute weak


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

[Bug c++/34939] [4.1/4.2 regression] ICE with friend and attribute weak

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-02-14 10:49 ---
Subject: Bug 34962

Author: jason
Date: Wed Feb 13 21:27:16 2008
New Revision: 132297

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132297
Log:
PR c++/34962, c++/34937, c++/34939
* decl2.c (is_late_template_attribute): Always defer attributes
vector_size and weak.

Added:
trunk/gcc/testsuite/g++.dg/ext/tmplattr9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE
   |with friend and attribute   |with friend and attribute
   |weak|weak


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

[Bug rtl-optimization/35190] Wrong branch instruction with -freorder-blocks-and-partition on SH

[kkojima at gcc dot gnu dot org]

--- Comment #2 from kkojima at gcc dot gnu dot org  2008-02-14 11:09 ---
Sure. 
I'll add the following comment for that.

@@ -1105,9 +1105,14 @@ update_equiv_regs (void)
  if (! INSN_P (insn))
continue;

- /* Don't substitute into a non-local goto, this confuses CFG.  */
+ /* Don't substitute into a non-local goto, this confuses CFG.
+Since bb-reorder uses indirect jumps for crossing branches
+when the architecture doesn't have unconditional branches
+that can span all of memory, don't touch a jump associated
+with a REG_CROSSING_JUMP note.  */
  if (JUMP_P (insn)
- && find_reg_note (insn, REG_NON_LOCAL_GOTO, NULL_RTX))
+ && (find_reg_note (insn, REG_NON_LOCAL_GOTO, NULL_RTX)
+ || find_reg_note (insn, REG_CROSSING_JUMP, NULL_RTX)))
continue;

  for (link = REG_NOTES (insn); link; link = XEXP (link, 1))


-- 


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

[Bug libfortran/35063] Clean up use of destroy_unit_mutex()

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |minor
   Keywords|wrong-code  |
Summary|[Regression wrt g77] I/O|Clean up use of
   |leaks handles/memory on |destroy_unit_mutex()
   |Windows XP  |
   Target Milestone|4.3.0   |4.4.0


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

[Bug c++/28743] [4.1/4.2/4.3 regression] ICE with invalid specialization

[paolo at gcc dot gnu dot org]

--- Comment #8 from paolo at gcc dot gnu dot org  2008-02-14 12:35 ---
Subject: Bug 28743

Author: paolo
Date: Thu Feb 14 12:34:42 2008
New Revision: 132316

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132316
Log:
/cp
2008-02-14  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/28743
* pt.c (determine_specialization): In case of function templates,
when the type of DECL does not match FN there is no match.

/testsuite
2008-02-14  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/28743
* g++.dg/template/nontype17.C: New.
* g++.dg/template/nontype16.C: Add error.

Added:
trunk/gcc/testsuite/g++.dg/template/nontype17.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/template/nontype16.C


-- 


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

[Bug c++/28743] [4.1/4.2 regression] ICE with invalid specialization

[pcarlini at suse dot de]

--- Comment #9 from pcarlini at suse dot de  2008-02-14 12:37 ---
Fixed for 4.3.0.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW
Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE
   |with invalid specialization |with invalid specialization


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

[Bug fortran/35150] ICE in expand_expr_addr_expr_1, at expr.c:6728 (regression vs. earlier 4.3)

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2008-02-14 12:42 
---
I've posted a workaround patch at
http://gcc.gnu.org/ml/fortran/2008-02/msg00092.html. My analysis is currently
as follow: we currently have

static void * * C.906 = &argv;
glutinit_gl (&C.906);

which leads to the ICE in expand_expr_addr_expr_1(). The code we emitted
before, when C_LOC wasn't inlined, was:

void * C.906 = _gfortran_c_loc (&argv);
glutinit_gl (&C.906);

where _gfortran_c_loc was effectively:

void * _gfortran_c_loc (void *p) { return p; }

As Tobias shown, the code taking care of taking the adress of argv
(constructing "&argv") is in function gfc_conv_function_call (in trans-expr.c).
I have tried to modify it by forcing a cast to pvoid_type_node, but it still
gets the "static" attribute later. The variable creation is not done in that
function, but later (and I cannot see why). If someone knows where, that would
be great.

PS: I think that translating the ISO_C_BINDING inlined functions in
gfc_conv_function_call() is actually too late. The intrinsic functions, for
example, are intercepted somewhere earlier in the code path, and I think that
would be better to do it in a similar way for intrinsic module functions (now,
ISO_C_BINDING, and later, IEEE_*).


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.3.0
   Last reconfirmed|-00-00 00:00:00 |2008-02-14 12:42:39
   date||
   Target Milestone|--- |4.3.0


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

--- Comment #31 from ubizjak at gmail dot com  2008-02-14 12:48 ---
(In reply to comment #30)

> participate to the discussion, but I think this PR only expose an underlying
> bug that should be analyzed.
> 
> From what I understand, if *STACK_BOUNDARY is larger than the size of what is
> pushed in the stack, some padding is performed. So the basic question is why
> this done for -O2 and not for -Os.

Well, _if_ we want STACK_BOUNDARY larger than PARM_BOUNDARY, then following
patch is needed:

ndex: function.c
===
--- function.c  (revision 132313)
+++ function.c  (working copy)
@@ -3436,7 +3436,7 @@ pad_to_arg_alignment (struct args_size *
 sp_offset = 0;
 #endif

-  if (boundary > PARM_BOUNDARY && boundary > STACK_BOUNDARY)
+  if (boundary > PARM_BOUNDARY || boundary > STACK_BOUNDARY)
 {
   save_var = offset_ptr->var;
   save_constant = offset_ptr->constant;
@@ -3462,7 +3462,7 @@ pad_to_arg_alignment (struct args_size *
  offset_ptr->var = size_binop (MINUS_EXPR, rounded, sp_offset_tree);
  /* ARGS_SIZE_TREE includes constant term.  */
  offset_ptr->constant = 0;
- if (boundary > PARM_BOUNDARY && boundary > STACK_BOUNDARY)
+ if (boundary > PARM_BOUNDARY || boundary > STACK_BOUNDARY)
alignment_pad->var = size_binop (MINUS_EXPR, offset_ptr->var,
 save_var);
}
@@ -3474,7 +3474,7 @@ pad_to_arg_alignment (struct args_size *
 #else
CEIL_ROUND (offset_ptr->constant + sp_offset, boundary_in_bytes);
 #endif
-   if (boundary > PARM_BOUNDARY && boundary > STACK_BOUNDARY)
+   if (boundary > PARM_BOUNDARY || boundary > STACK_BOUNDARY)
  alignment_pad->constant = offset_ptr->constant - save_constant;
}
 }


This patch fixes va-arg-25.c testcase I'm testing with STACK_BOUNDARY = 128.
The patch bootstraps and regression tests on i686-pc-linux-gnu, but due to
STACK_BOUNDARY == PARM_BOUNDARY on this target, it has not much effect there.

Without this patch, alignment pad is always 0, which is just wrong for
va-arg-25.c case with mixed int/SSE/int/SSE arguments pushed on stack. Note
that sse requires 16 byte alignment.

Using -maccumulate-outgoing-args (-O2), we subtract %esp and stick arguments
into the call frame using offseted moves. We have no other %esp manipulation in
this case.


-- 


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

[Bug target/34930] [4.3 Regression] ICE in instantiate_virtual_regs_in_insn with vector splat load

[matz at gcc dot gnu dot org]

--- Comment #13 from matz at gcc dot gnu dot org  2008-02-14 12:55 ---
Subject: Bug 34930

Author: matz
Date: Thu Feb 14 12:54:30 2008
New Revision: 132317

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132317
Log:
PR target/34930
* function.c (instantiate_virtual_regs_in_insn): Reload address
before falling back to reloading the whole operand.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c


-- 


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

[Bug target/34930] [4.3 Regression] ICE in instantiate_virtual_regs_in_insn with vector splat load

[matz at gcc dot gnu dot org]

--- Comment #14 from matz at gcc dot gnu dot org  2008-02-14 12:55 ---
Fixed in r132317.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c/35193] New: can't find a register in class 'R1_REGS' while reloading 'asm'

[b dot gunreben at web dot de]

when I try to compile a current glibc for hppa, I get the following error:
gcc -O2 -c dcigettext.i
dcigettext.c: In function ‘_nl_find_msg’:
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:220: error: can't
find a register in class 'R1_REGS' while reloading 'asm'
dcigettext.c:1102: error: can't find a register in class 'R1_REGS' while
reloading 'asm'
dcigettext.c:1164: error: can't find a register in class 'R1_REGS' while
reloading 'asm'
dcigettext.c:1194: error: can't find a register in class 'R1_REGS' while
reloading 'asm'
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:220: error: 'asm'
operand has impossible constraints
dcigettext.c:1102: error: 'asm' operand has impossible constraints
dcigettext.c:1164: error: 'asm' operand has impossible constraints
dcigettext.c:1194: error: 'asm' operand has impossible constraints

however, if I remove the lines with starting # signs in the preprocessed code
like:

grep -v "^#" dcigettext.i > x.i

it just compiles. The original error also vanishes if I use -O instead of -O2.
Adding preprocessed dcigettext.i, to reproduce, run 

gcc -O2 -c dcigettext.i


-- 
   Summary: can't find a register in class 'R1_REGS' while reloading
'asm'
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: b dot gunreben at web dot de
  GCC host triplet: hppa-suse-linux-gnu


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

[Bug c/35193] can't find a register in class 'R1_REGS' while reloading 'asm'

[b dot gunreben at web dot de]

--- Comment #1 from b dot gunreben at web dot de  2008-02-14 13:28 ---
Created an attachment (id=15148)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15148&action=view)
preprocessed dcigettext.i


-- 


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

[Bug ada/35194] New: floating point truncation error on intel platform

[jerome dot duquennoy at wanadoo dot fr]

In some situations (after a call to a C oracle function, or when running the
program on top of valgrind), floats behave strangely : a given, hard coded
float value displays erroneously.
For exemple, a float value of 1.2001 would print as "1.20831E+0".

Our analysis :
We reproduced the problem either using functions from the Oracle C library or
running the software on top of valgrind.
The tests were done on a Suse Linux 10.0 and a centos 5.1, using a 4.1.2
compiler and a 4.2.3 compiler, running on an intel-based machine (core2duo and
pentium D).
We COULD NOT reproduce the problem on a solaris 9 UltraSPARC III based machine.

Using a customized img_real package, we found that the bad behaving code is the
Long_Long_Float'Truncation attribute, called in the Convert_Integer procedure
of the Set_Image_Real procedure, in package img_real.

This function seems to be platform-dependent, this is coherent with the
behaviour difference between a sparc-based machine and an pentium-based one.

The problem can be reproduced easily by compiling this simple code, and running
the executable under Valgrind :


with 
ada.text_io, 
Ada.Strings.Fixed,
System.img_real;

use 
Ada.Strings.Fixed, 
ada.text_io,
System.img_real;

procedure test_fio is  
   value : Long_Long_Float;

resulting_string : string(1..15);
nat : natural;
begin
   value := 1.2001;
   resulting_string := (others => ' '); 
nat := 0;

set_image_real(value, resulting_string, nat, 2, 4, 2);

put_line ("resulting_string : '" & resulting_string & "'");
end test_fio;


-- 
   Summary: floating point truncation error on intel platform
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jerome dot duquennoy at wanadoo dot fr


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

[Bug ada/35194] floating point truncation error on intel platform

[jerome dot duquennoy at wanadoo dot fr]

--- Comment #1 from jerome dot duquennoy at wanadoo dot fr  2008-02-14 
13:38 ---
Created an attachment (id=15149)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15149&action=view)
Simple source code to reproduce the bug

Compile this code and run the resulting binary on top of valgrind to reproduce
the bug.


-- 


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

[Bug c++/35117] Vectorization on power PC

[victork at gcc dot gnu dot org]

--- Comment #34 from victork at gcc dot gnu dot org  2008-02-14 13:41 
---
> How do I resolve those issues? which might prevent from the vectorized code to
> run and therefore I dont see a bigger performance improvement?
> I'd appriciate any assistance...

This note is just information and not warning. It means that compiler cannot
prove independence of data arrays which are candidates for vectorization. It's
hard to say how to help to compiler to prove dependence statically without
seeing your source code. You can try "restrict" attribute. Still sometimes
dependence cannot be proven at compile time, and run-time check is necessary.
This run-time check adds some overhead, but for loops with large enough number
of iterations the overhead is diminishing.


-- 

victork at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/35182] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-02-14 13:43 ---
Reduced testcase, which shows this is inlining related and not related to
PR34989.  Honza, can you have a look?  After inlining we have:

:
  # iter_6 = PHI 

where clearly iter_6 should be marked abnormal?  But I also don't see who
messes up between sdse2 and apply_inline (we don't seem to inline anything
after all).


struct __shared_count {
__shared_count() { _M_pi = new int; }
int * _M_pi;
};
template
class __shared_ptr {
public:
__shared_ptr(_Tp* __p);
void reset(int * __p) {
__shared_ptr(__p).swap(*this);
}
void swap(__shared_ptr<_Tp>& __other) {
__other._M_refcount._M_pi = _M_refcount._M_pi;
}
__shared_count _M_refcount;
};
template class shared_ptr : public __shared_ptr<_Tp> {};
int main() {
for (shared_ptr *iter;;)
{
try {
(iter++)->reset(new int);
}
catch (...) {
}
}
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
   Priority|P3  |P1


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

[Bug ada/35194] floating point truncation error on intel platform

[jerome dot duquennoy at wanadoo dot fr]

--- Comment #2 from jerome dot duquennoy at wanadoo dot fr  2008-02-14 
13:44 ---
A precision on the appearance of the bug :
The bug first appears when using the Oracle 10 C library (libclntsh), and can
be reproduced using the Oracle 11 library.
The bug does not appear when using Oracle 9.


-- 


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

[Bug c++/35182] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-02-14 13:46 ---
That is, somehow we split an edge:

+:
+  goto ;
+
 :
-  # iter_1(ab) = PHI 
+  # iter_6 = PHI 
+
+:
+  # iter_1(ab) = PHI 
   D.2093_4 = operator new (4);

 :

but mess up somehow.


-- 


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

[Bug c++/35159] g++ inoperable with no error message

[nightstrike at gmail dot com]

--- Comment #12 from nightstrike at gmail dot com  2008-02-14 14:27 ---
Subject: Re:  g++ inoperable with no error message

On 14 Feb 2008 08:15:35 -, jakub at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #5 from jakub at gcc dot gnu dot org  2008-02-14 08:15 ---
> It would be helpful if you could post the actual errors that are reported for
> the ICE, perhaps backtrace and other details.  Guess most of the people don't
> have access to this target and I doubt it can be reproduced using a cross
> compiler.

One of the issues is that there isn't any error output from g++.  In
fact, that's probably the most disturbing part -- g++ will die
silently, giving zero output, zero errors, zero anything.  Under some
situations, you might be able to get an ICE when you use -E, but it
says that the ICE occurred in ":0", which isn't too helpful.


-- 


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

[Bug c++/35159] g++ inoperable with no error message

[nightstrike at gmail dot com]

--- Comment #13 from nightstrike at gmail dot com  2008-02-14 14:29 ---
Addendum - this applies to gfortran, as well.


-- 


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

[Bug target/35195] New: Strange effect of -msse5/-mno-sse5

[hjl dot tools at gmail dot com]

bash-3.2$ cat y.c
#include 

int
main ()
{
#ifdef __MMX__
  printf ("MMX\n");
#endif
#ifdef __3dNOW__
  printf ("3dNOW\n");
#endif
#ifdef __3dNOW_A__
  printf ("3dNOW_A\n");
#endif
}
bash-3.2$ /usr/gcc-4.3/bin/gcc -march=k8 -msse5 y.c && ./a.out 
MMX
3dNOW
3dNOW_A
bash-3.2$ /usr/gcc-4.3/bin/gcc -march=k8 -mno-sse5 y.c && ./a.out
MMX
bash-3.2$ 

Why does -mno-sse5 turn off 3dNOW and 3dNOW_A?


-- 
   Summary: Strange effect of -msse5/-mno-sse5
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

asdasd

[agi]

Szia!

Csak azert irok neked mert szeretnem felhivni a figyelemedet magyarorszag egyik 
legnagyobb warez oldalara,ami nem reg keszult el es mar tobb 100 regisztralt 
felhasznalonk van! a legujabb PREMIER filmek,mp3,games,sorozatok,stb Ha te is 
csatlakozni szeretnel nezd meg az oldalunkat http://join.media20.eu cimen 
erheto el.

[Bug c++/35183] ice for illegal code

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-02-14 14:48 ---
It used to compile with "4.3.0 20080128".


-- 


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

[Bug c++/35183] ice for illegal code

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-02-14 14:55 ---
This is already fixed with "4.3.0 20080213".

*** This bug has been marked as a duplicate of 35116 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/35116] [4.3 Regression]: Fail to compile valid code

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-02-14 14:55 ---
*** Bug 35183 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com


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

[Bug libstdc++/33983] and invalid_argument name clash with -std=gnu++0x

[pcarlini at suse dot de]

--- Comment #5 from pcarlini at suse dot de  2008-02-14 15:40 ---


*** This bug has been marked as a duplicate of 34538 ***


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|c++ |libstdc++
 Resolution||DUPLICATE


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

[Bug libstdc++/34538] [DR 697] combination of sstream, invalid_argument and -std=c++0x breaks valid code

[pcarlini at suse dot de]

--- Comment #9 from pcarlini at suse dot de  2008-02-14 15:40 ---
*** Bug 33983 has been marked as a duplicate of this bug. ***


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||cppljevans at suddenlink dot
   ||net


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

[Bug c++/35182] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges

[hubicka at gcc dot gnu dot org]

--- Comment #6 from hubicka at gcc dot gnu dot org  2008-02-14 15:54 ---
I am going to take a look. Where we split the edge?

Honza


-- 


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

[Bug target/35071] bad instruction `do_itt eq'

[drow at gcc dot gnu dot org]

--- Comment #5 from drow at gcc dot gnu dot org  2008-02-14 16:11 ---
Looks like it should be "do_it eq, t".  Each additional "t" or "e" predicates
one more instruction.  The mvfeqd has to be predicated and so does the
RETc(eq).


-- 


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

[Bug middle-end/35196] [4.3 Regression] lastprivate broken for static non-ordered loops

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||openmp
  Known to fail||4.3.0
  Known to work||4.2.0
   Target Milestone|--- |4.3.0


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

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[drow at gcc dot gnu dot org]

--- Comment #11 from drow at gcc dot gnu dot org  2008-02-14 16:31 ---
Might want to try at least one SPE target, for completeness.  I think
powerpc-*-eabispe is sim testable.


-- 


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

[Bug c++/35182] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges

[rguenther at suse dot de]

--- Comment #7 from rguenther at suse dot de  2008-02-14 16:16 ---
Subject: Re:  [4.2/4.3 Regression] ICE in coalesce_abnormal_edges

On Thu, 14 Feb 2008, hubicka at gcc dot gnu dot org wrote:

> --- Comment #6 from hubicka at gcc dot gnu dot org  2008-02-14 15:54 
> ---
> I am going to take a look. Where we split the edge?

Somewhere between sdse2 and after final inlining (I didn't investigate).

Richard.


-- 


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

[Bug target/35071] bad instruction `do_itt eq'

[joel at gcc dot gnu dot org]

--- Comment #6 from joel at gcc dot gnu dot org  2008-02-14 16:30 ---
(In reply to comment #5)
> Looks like it should be "do_it eq, t".  Each additional "t" or "e" predicates
> one more instruction.  The mvfeqd has to be predicated and so does the
> RETc(eq).
> 

Do you want to commit that?


-- 


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

[Bug middle-end/35196] New: [4.3 Regression] lastprivate broken for static non-ordered loops

[jakub at gcc dot gnu dot org]

extern void abort (void);
extern void omp_set_dynamic (int);

int
main (void)
{
  int i, j;
  omp_set_dynamic (0);
#pragma omp parallel for lastprivate (i, j) num_threads (8)
  for (i = 0; i < 5; i++)
j = i;
  if (i != 5 || j != 4)
abort ();
  return 0;
}

fails with -fopenmp since
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128223
sporadically.  If some thread is assigned no iterations of the loop and is
scheduled after the thread which invokes last iteration, lastprivate vars other
than the loop counter will have wrong values.

Before that commit we ompexped:
  i = 0;
  D.1566 = __builtin_omp_get_num_threads ();
  D.1567 = __builtin_omp_get_thread_num ();
  D.1568 = 5 / D.1566;
  D.1569 = D.1568 * D.1566;
  D.1570 = D.1569 != 5;
  D.1571 = D.1568 + D.1570;
  D.1572 = D.1571 * D.1567;
  D.1573 = D.1572 + D.1571;
  D.1574 = MIN_EXPR ;
  if (D.1572 >= D.1574)
goto ;
  else
goto ;

:
  if (i == 5)
goto ;
  else
goto ;

:
  return;

:
  .omp_data_i->i = i;
  .omp_data_i->j = j;
  goto ;

:
  D.1575 = D.1572 * 1;
  i = D.1575 + 0;
  D.1576 = D.1574 * 1;
  D.1577 = D.1576 + 0;

:
  j = i;
  i = i + 1;
  D.1578 = i < D.1577;
  if (D.1578)
goto ;
  else
goto ;

i.e. if no iterations are given to the thread, the counter will have a value
different from the final value.
After the commit we have:
  i = 0;
  D.1576 = __builtin_omp_get_num_threads ();
  D.1577 = __builtin_omp_get_thread_num ();
  D.1578 = 5 / D.1576;
  D.1579 = D.1578 * D.1576;
  D.1580 = D.1579 != 5;
  D.1581 = D.1580 + D.1578;
  D.1582 = D.1581 * D.1577;
  D.1583 = D.1582 + D.1581;
  D.1584 = MIN_EXPR ;
  i = D.1582;
  if (D.1582 >= D.1584)
goto ;
  else
goto ;

:
  j = i;
  i = i + 1;
  if (i < D.1584)
goto ;
  else
goto ;

:
  if (i == 5)
goto ;
  else
goto ;

:
  return;

:
  .omp_data_i->i = i;
  .omp_data_i->j = j;
  goto ;

where the iteration var is set already right after MIN_EXPR, rather than only
if some iterations were given to the thread.


-- 
   Summary: [4.3 Regression] lastprivate broken for static non-
ordered loops
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

--- Comment #32 from ubizjak at gmail dot com  2008-02-14 17:08 ---
Dominique, could you regtest
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00507.html on darwin?


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||02/msg00507.html


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

[Bug target/35071] bad instruction `do_itt eq'

[corsepiu at gcc dot gnu dot org]

--- Comment #7 from corsepiu at gcc dot gnu dot org  2008-02-14 17:26 
---
Created an attachment (id=15150)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15150&action=view)
patch implementing drow's proposal

I have no idea what this patch actually does, but it at least lets
arm-rtems*-gcc bootstrap ;)


-- 


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

[Bug target/35018] [m68k-elf] Gcc ouputs invalid asm when compiling with -O2 or higher

[schwab at suse dot de]

--- Comment #2 from schwab at suse dot de  2008-02-14 17:35 ---
The problem is in the addsi_lshrsi_31 insn:

(define_insn "addsi_lshrsi_31"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=dm")
(plus:SI (lshiftrt:SI (match_operand:SI 1 "general_operand" "rm")
(const_int 31))
(match_dup 1)))]
  ""
{
  operands[2] = operands[0];
  operands[3] = gen_label_rtx();
  if (GET_CODE (operands[0]) == MEM)
{
  if (GET_CODE (XEXP (operands[0], 0)) == POST_INC)
operands[0] = gen_rtx_MEM (SImode, XEXP (XEXP (operands[0], 0), 0));
  else if (GET_CODE (XEXP (operands[0], 0)) == PRE_DEC)
operands[2] = gen_rtx_MEM (SImode, XEXP (XEXP (operands[0], 0), 0));
}
  output_asm_insn ("move%.l %1,%0", operands);

The constraints are wrong for coldfire.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   GCC host triplet|Linux amd 64|
   Last reconfirmed|-00-00 00:00:00 |2008-02-14 17:35:39
   date||


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

[Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.

[dannysmith at users dot sourceforge dot net]

--- Comment #7 from dannysmith at users dot sourceforge dot net  2008-02-14 
17:46 ---
(In reply to comment #6)
> I agree, that the havoc for 32-bit backward compatibility is to avoid.
> But the havoc for windows sources using -fno-builtin and using _alloca () for
> stack allocation produces in future even more troubles IMHO.

Why should windows sources need to use __alloca.

If someone really wants an MSCV compatible (one underscore)  _alloca they just
add this to their srcs
void *_alloca (size_t size) {return __builtin_alloca (size));


MSDN documentation says that "This function is deprecated because a more secure
version is available; see _malloca."


-- 


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

[Bug libstdc++/35197] New: Native linker can't locate file for -lstdc++ with --enable-version-specific-runtime-libs

[skunk at iskunk dot org]

I have a build of GCC 4.2.3 compiled with
--enable-version-specific-runtime-libs. It fails to link a trivial C++ program,
because the (non-GNU) linker does not know about libstdc++, and the GCC
frontend is not passing an appropriate -L... flag to the linker so that it can
find the library.

$ g++ -o hello hello.cxx
/usr/bin/ld:
Can't locate file for: -lstdc++
collect2: ld returned 1 exit status

$ g++ -v -o hello hello.cxx
[superfluous verbiage elided]
mips-tfile (GCC) 4.2.3
 /opt/tg/bin/../libexec/gcc/alphaev56-dec-osf4.0g/4.2.3/collect2 -G 8 -O1 -S
-call_shared -o hello /usr/lib/cmplrs/cc/crt0.o
-L/opt/tg/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.2.3 -L/opt/tg/bin/../lib/gcc
-L/opt/tg/lib/gcc/alphaev56-dec-osf4.0g/4.2.3 -L/usr/lib/cmplrs/cc
-L/opt/tg/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.2.3/../../..
-L/opt/tg/lib/gcc/alphaev56-dec-osf4.0g/4.2.3/../../.. /tmp//ccu9eHi9.o
-lstdc++ -lm -lgcc -lc -lgcc
/usr/bin/ld:
Can't locate file for: -lstdc++
collect2: ld returned 1 exit status

(I notice that libstdc++ is present immediately under
/opt/tg/lib/gcc/alphaev56-dec-osf4.0g/, which the -L... flags narrowly miss.)


-- 
   Summary: Native linker can't locate file for -lstdc++ with --
enable-version-specific-runtime-libs
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
 GCC build triplet: alphaev56-dec-osf4.0g
  GCC host triplet: alphaev56-dec-osf4.0g
GCC target triplet: alphaev56-dec-osf4.0g


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

[Bug other/35199] New: [PATCH] Check for valid value of BASEVER

[skunk at iskunk dot org]

I was recently bootstrapping GCC4 on Tru64. One thing that tripped me up a
couple times was an ICE resulting from an invalid version_string (""). I traced
this back to the following fragment in gcc/Makefile, where BASEVER_c is
assigned:

BASEVER := $(srcdir)/BASE-VER  # 4.x.y
[...]
BASEVER_c   := $(shell cat $(BASEVER))

For some reason, the value of BASEVER_c was empty. I had the source tree on
NFS, and figured that some transient error caused $(BASEVER) to either
disappear momentarily, or briefly appear as an empty file. (It's difficult to
say, because the rest of the build proceeded with no errors of this sort
whatsoever.)

Whatever the cause, the makefile as currently written does not check for an
empty value of BASEVER_c, and the ICE that later results from this is
magnitudes of order more difficult to diagnose for most users. I would like to
submit a patch to the makefile, then, that immediately throws an error if
BASEVER_c is empty.


-- 
   Summary: [PATCH] Check for valid value of BASEVER
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org


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

[Bug other/35199] [PATCH] Check for valid value of BASEVER

[skunk at iskunk dot org]

--- Comment #1 from skunk at iskunk dot org  2008-02-14 19:01 ---
Created an attachment (id=15151)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15151&action=view)
Patch against gcc/Makefile.in


-- 


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

[Bug middle-end/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on

[ebotcazou at gcc dot gnu dot org]

--- Comment #19 from ebotcazou at gcc dot gnu dot org  2008-02-14 19:10 
---
Hopefully for real this time.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on

[ebotcazou at gcc dot gnu dot org]

--- Comment #18 from ebotcazou at gcc dot gnu dot org  2008-02-14 19:08 
---
Subject: Bug 35136

Author: ebotcazou
Date: Thu Feb 14 19:07:38 2008
New Revision: 132320

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132320
Log:
PR middle-end/35136
* gimplify.c (force_gimple_operand_bsi): Revert 2008-02-12 change.
(force_gimple_operand): Likewise.
* tree-ssa-loop-ivopts.c (may_be_nonaddressable_p): Add new cases
for TARGET_MEM_REF and CONVERT_EXPR/NON_LVALUE_EXPR/NOP_EXPR.
Also recurse on the operand for regular VIEW_CONVERT_EXPRs.
(find_interesting_uses_address): Check addressability and alignment
of the base expression only after substituting bases of IVs into it.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/tree-ssa-loop-ivopts.c


-- 


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

[Bug c/35198] New: missed evaluation of VM array type

[mrs at apple dot com]

void* a(void* x) {return (int (*)[10][printf("hi\n")])x;}
  int main() { int i; a(&i); }

should print hi.  This was still broken in 4.3 in July, 2007.


-- 
   Summary: missed evaluation of VM array type
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug bootstrap/35199] [PATCH] Check for valid value of BASEVER

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-02-14 19:33 ---
BASE-VER should always exist.

Also patches should be posted to [EMAIL PROTECTED]


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
  Component|other   |bootstrap


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

[Bug tree-optimization/35200] [4.3 Regression] gcc 4.3 failed to compile binutils

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-02-14 19:52 ---
Created an attachment (id=15152)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15152&action=view)
A testcase


-- 


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

[Bug tree-optimization/35200] [4.3 Regression] gcc 4.3 failed to compile binutils

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-02-14 19:57 ---
H, I think this might be a valid warning.


-- 


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

[Bug tree-optimization/35200] [4.3 Regression] bogus aliasing warning

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-02-14 20:00 ---
Oh there is an union here.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal
   Keywords||diagnostic
Summary|[4.3 Regression] gcc 4.3|[4.3 Regression] bogus
   |failed to compile binutils  |aliasing warning
   Target Milestone|--- |4.3.0


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

[Bug tree-optimization/35200] New: [4.3 Regression] gcc 4.3 failed to compile binutils

[hjl dot tools at gmail dot com]

Gcc 4.3 revision 132310 gives bogus error when compiling binutils
on Linux/ia32:

[EMAIL PROTECTED] gas]$ /usr/gcc-4.3/bin/gcc -O2 x.i -S -Wall
x.c: In function ‘operand_type_match’:
x.c:1025: warning: likely type-punning may break strict-aliasing rules: object
‘*{unknown}’ of main type ‘unsigned int’ is referenced at or around x.c:1025
and may be aliased to object ‘{unknown}’ of main type ‘unsigned char:1’ which
is referenced at or around x.c:1025.


This error is very sensitive to gcc revision as well as the input.
If I remove a blank line in the source, I won't see the error. It is
also OK if I compile it on Linux/Intel64 with -m32.


-- 
   Summary: [4.3 Regression] gcc 4.3 failed to compile binutils
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[dominiq at lps dot ens dot fr]

--- Comment #33 from dominiq at lps dot ens dot fr  2008-02-14 19:37 ---
> Dominique, could you regtest

I just finished a fresh build, I'll start to regtest as soon as the install is
finished, the full regtest takes approximately 5 hours, so the results will
only be available tomorrow morning. I have checked that the patch fix this PR.


-- 


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

[Bug c++/35201] New: libdemangle no longer distinguishes constructor/destructor variants

[sanjay3000 at gmail dot com]

The C++ ABI at http://www.codesourcery.com/cxx-abi/abi.html defines:

  ::= C1 # complete object constructor
 ::= C2 # base object constructor
 ::= C3 # complete object allocating constructor
 ::= D0 # deleting destructor
 ::= D1 # complete object destructor
 ::= D2 # base object destructor

However, libdemange/c++filt no longer translate those specifiers. I think this
is a regression from previous revisions of the library. They used to specify
"in-charge" or other strings for the various ctor/dtor flavors.

Example of raw constructor string:
_ZN9DagSymbolC2Ev
_ZN9DagSymbolC1Ev

These both are demangled as:
DagSymbol::DagSymbol()


-- 
   Summary: libdemangle no longer distinguishes
constructor/destructor variants
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sanjay3000 at gmail dot com


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

[Bug tree-optimization/35200] [4.3 Regression] bogus aliasing warning

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-02-14 20:21 ---
Can you when you debug the function, please dump the VOPs also since then it
should become obvious the issue.

Anyways I don't think this an bogus warning and really I think this is a code
issue.

This is actually documented this way in fact unions cannot be used this way.

That is you cannot do:

float f(int a)
{
  union {
  int i[1];
  float f[1];
  } g;

  int *d = g.i;
  float *f = g.f;
  *d = a;
  return *f;
}

-- Pinski


-- 

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=35200

[Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.

[dannysmith at users dot sourceforge dot net]

--- Comment #8 from dannysmith at users dot sourceforge dot net  2008-02-14 
20:10 ---
(In reply to comment #7)

> If someone really wants an MSCV compatible (one underscore)  _alloca they just
> add this to their srcs
> void *_alloca (size_t size) {return __builtin_alloca (size));
> 
Ugh. Sorry, I wasn't thinking clearly. Currently, that will lead to circular
reference.  I'll change gen_allocate_stack_worker to use __chkstk for 32-bits
when 4.4. opens.
Just #define _alloca __builtin_alloca,  That isn't affected by -fno-builtin
anyway
Danny

> 
> MSDN documentation says that "This function is deprecated because a more 
> secure
> version is available; see _malloca."
> 


-- 


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

[Bug tree-optimization/35200] [4.3 Regression] bogus aliasing warning

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-02-14 20:16 ---
The first time we saw it is last Nov. But it is very hard to reproduce.
Any changes in input will make the warning to disappear. Here is what
Xuepeng got

The warning are caused by SSA and type-punning:

[EMAIL PROTECTED] gas]$ cat foo.c
typedef union i386_operand_type
{
  struct
{
  unsigned int reg8:1;
} bitfield;
  unsigned int array[1];
} i386_operand_type;

extern void f(int *p)
{
  *p = 100;
}

int main()
{
  i386_operand_type t;

  t.bitfield.reg8 = 1;

  f(&t.array[1]);

  return 0;
}
[EMAIL PROTECTED] gas]$ /usr/gcc-4.3/bin/gcc -O2 foo.c -S -Wall
foo.c: In function ‘main’:
foo.c:21: warning: pointer targets in passing argument 1 of ‘f’ differ in
signedness
foo.c:21: warning: likely type-punning may break strict-aliasing rules: object
‘*{unknown}’ of main type ‘int’ is referenced at or around foo.c:12 and may be
aliased to object ‘{unknown}’ of main type ‘unsigned char:1’ which is
referenced at or around foo.c:21.
[EMAIL PROTECTED] gas]$ 

It's not the exactly extracted case. But it's enough to
explain the bug698. The SSA and function-inline bring about this bug. If using
-fdump-tree-salias we can get .salias file for the exacted case in which you
can see that compiler will generate a STRUCTURE-FIELD-TAG tree node for each
field of union t, like below:

;;Function main(main)

structure field tag SFT.13 created for var t offset 33 size 31
structrue field tag SFT.14 created for var t offset 32 size 32
structrue field tag SFT.15 created for var t offset 32 size 1
...
structrue field tag SFT.47 created for var t offset 0 size 32
structrue field tag SFT.48 created for var t offset 0 size 1

Here we can treat the SFT.x as a pointer that points to the field of t. So the
SFT.13 is a pointer that points to t.bitfield.unused whose offset is 33 and
size is 31 and main type is assumed as "unsigned int:31", SFT.14 is a pointer
that points to t.array[1] whose offset is 32 and size is 32 and main type is
int, SFT.15 points t.bitfield.regmem whose offset is 32 and size is 1 and main
type is assumed as "unsigned char:1".

Because of -O2, the function main will inline the function f, the final codes
look like below:

main()
{
  union i386_operand_type t;
  int i;
  int *D.1586;
:
  t.bitfield.reg8 = 1;
  D.1586_1 = (int *)&t.array;
  i_6 = *D.1586_1;
  return i_6;
}

D.1586_1 is a pointer in SSA form that points to t.array and will be used in
the next line. So according to strict aliasing rules, D.1586_1 will be conflict
with SFT.13~SFT.48 because their main types are different(except SFT.14 and
SFT.47)but point to the same memory area union t. The number of warnings equals
to the number of SFT.

In tc-i386.c, function uints_equal has statements:

case 2:
 if(x[1]!=y[1])
return 0;
..

function  update_imm has statements:

if((&&!UINTS_EQUAL(overlap, imm8) &&...))


and function md_assemble calls function finalize_imm, and finalize_imme calls
update_imm, update_imm calls uints_equal. The optimization of function-inline
will get final statements(in ssa form) like below:

structure field tag SFT.10215 created for var imm8 offset 33 size 31


:;
  ...
  D.29407_741 = &imm8.array[1];
  D.29408_742 = *D.29407_741
  ...

So the ssa variable D.29407_741 is conflict with SFT.10215(and others)
according to the strict-aliasing rules. And please notice that without the
using in the next line, without this warning.

You may be wonder that why I am sure about my conclusion. That because there is
only one place in gcc source files to generate this warning, function
strict_aliasing_warn(tree alias_site, tree object1, bool is_ptr1, tree object2,
bool is_ptr2, bool filter_artificials) in tree-ssa-alias-warnings.c. I have
debuged into this function and investigated the object1 and object2. So it
does.

If you modified the file tc-i386.c, the compiler will not inline some specific
functions based on the inline strategy and at last you won't get code like
above and warnings. That's why I have said it's "unstable".


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||Joey dot ye at intel dot
   ||com, xuepeng dot guo at
   ||intel dot com


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

[Bug tree-optimization/35200] [4.3 Regression] bogus aliasing warning

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2008-02-14 20:54 ---
(In reply to comment #5)
> Can you when you debug the function, please dump the VOPs also since then it
> should become obvious the issue.
> 
> Anyways I don't think this an bogus warning and really I think this is a code
> issue.
> 
> This is actually documented this way in fact unions cannot be used this way.
> 
> That is you cannot do:
> 
> float f(int a)
> {
>   union {
>   int i[1];
>   float f[1];
>   } g;
> 
>   int *d = g.i;
>   float *f = g.f;
>   *d = a;
>   return *f;
> }
> 
> -- Pinski
> 

Where is this documented in ISO C?


-- 


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

[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-02-14 21:33 ---
Yes, so for packed structs (which are a GCCism), GCC sets the rule.  Better
documentation is certainly appreciated, but - what is the bug here?  Did
the behavior change (I think it did for some 3.x releases) recently?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/35147] ICE trying to expand an argument pack with zero arguments

[dgregor at gcc dot gnu dot org]

--- Comment #1 from dgregor at gcc dot gnu dot org  2008-02-14 21:38 ---
This code is actually ill-formed. The problem is here:

  bind(h, forward(args...))

For N arguments, the second argument expands to:

  bind(h, forward(args1, args2, ..., argsN))

However, that's ill-formed because forward() accepts one template argument and
one function argument. We should have given a better error message when we try
to instantiate it with 0 arguments (instead, we crash).

The intent of the example is for the second argument to expand into "N"
different arguments:

  bind(h, forward(args1), forward(args2), ...,
forward(argsN>)

That can be expressed like so:

  bind(h, forward(args)...)

With that change, and replacing "h" (a function) with "c" (the Callable
function object given to this function), this program runs.

Here is a simpler test case that produces the same compile-time failure without
including any C++0x headers:

template
  inline _Tp&& forward(_Tp&& __t) { return __t; }


void f(...);

template
void g(Args&&... args)
{
  f(forward(args...));
}

void h()
{
  g();
}


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
   Last reconfirmed|-00-00 00:00:00 |2008-02-14 21:38:40
   date||


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

[Bug tree-optimization/35200] [4.3 Regression] bogus aliasing warning

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-02-14 21:23 ---
See 6.5/6 and /7


-- 


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

[Bug c++/35145] Mozilla stable branch (1.8) fails to build with gcc 4.3.0

[kengert at redhat dot com]

--- Comment #4 from kengert at redhat dot com  2008-02-14 21:35 ---
Andrew, thanks a lot for your comments.
It turns out the bug was indeed caused by Mozilla code, see the Mozilla bug.
Closing as INVALID.


-- 

kengert at redhat dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug c++/35022] [4.3 regression] ICE with parameter pack in template constant parameter

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-30 10:09:31 |2008-02-14 21:41:02
   date||


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

[Bug tree-optimization/35200] [4.3 Regression] bogus aliasing warning

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-02-14 21:19 ---
ISO C even disallows type-punning with unions (which is in fact a GNU
extension):

union { int i; float f } u;
u.i = 1;
return u.f;

invokes undefined behavior in ISO C.  You have to use memcpy and two different
memory objects like

int i = 1;
float f;
memcpy (&f, &i, 4);
return f;

to be portable and ISO C conformant.


-- 


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

[Bug c++/35026] [4.3 regression] ICE with parameter pack in pointer type

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-30 10:05:22 |2008-02-14 21:45:58
   date||


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

[Bug tree-optimization/35202] New: [4.1/4.2/4.3 Regression] exp->expf transformation incorrect with -fmath-errno

[jsm28 at gcc dot gnu dot org]

GCC converts calls such as (float)exp((double)f), where f is a float, into
calls to the corresponding mathematical functions for float, such as expf.

However, if the result overflows the range of float but not that of double, the
conversion is unsafe with -fmath-errno (on by default on most targets): errno
may be set by the call to the float function but not by the call to the double
function, so the compiler may be wrongly causing errno to be set for such
arguments.

This problem applies to all of the functions where the result for some float
argument overflows the range of float but not double.

(This is a regression from the compiler versions without this optimization.)


-- 
   Summary: [4.1/4.2/4.3 Regression] exp->expf transformation
incorrect with -fmath-errno
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org


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

[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ

[alexandre dot nunes at gmail dot com]

--- Comment #8 from alexandre dot nunes at gmail dot com  2008-02-14 22:06 
---
(In reply to comment #7)
> Yes, so for packed structs (which are a GCCism), GCC sets the rule.  Better
> documentation is certainly appreciated, but - what is the bug here?  Did
> the behavior change (I think it did for some 3.x releases) recently?
> 

I'm not sure if it's a bug, call it a clarification request, that may or may
not involve a bug: It's stated somewhere in gcc docs that gcc tries to do
things uniformly, only diverging between targets where there's a compelling
reason to do so. So what I'm asking is:

- Is the attribute((packed)) behaviour consistent between gcc ports regarding
bitfield alignments? If not, why?

- If attribute((packed)) is not consistent between gcc ports, could it be made
so? At least sysv abi (as far as I've read) does not mandate anything about the
bitfields within a word. I've not pointed to any ABI that does, however, that
was the explanation I've got. That's where I said the abi could change (for
several arches). You may say it's not worthy, and I would agree, but here is
where the "bug" would (or would not) lie.

- If not and there's no point changing it, could there be another attribute, or
anything, that would have that effect (uniformity between ABIs)?

I understand perfectly that using structures like that is meant to be
non-portable, but it's quite handy to have something like that without too much
worry about platforms, since altough I develop for several arches, almost all
of them today have a gcc port, and I know there are others with similar issues.

If this revert to be a non-bug and I can still hold a feature request on it, I
would be satisfied.


-- 


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

Re: [Bug tree-optimization/35200] [4.3 Regression] bogus aliasing warning

[Andrew Pinski]

On 14 Feb 2008 20:54:18 -, hjl dot tools at gmail dot com
<[EMAIL PROTECTED]> wrote:
>  Where is this documented in ISO C?

There is a Defect Report explicitly about this:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_236.htm

-- Pinski

[Bug tree-optimization/35202] [4.1/4.2/4.3 Regression] exp->expf transformation incorrect with -fmath-errno

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.1.3


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

[Bug tree-optimization/35200] [4.3 Regression] bogus aliasing warning

[pinskia at gmail dot com]

--- Comment #9 from pinskia at gmail dot com  2008-02-14 22:09 ---
Subject: Re:  [4.3 Regression] bogus aliasing warning

On 14 Feb 2008 20:54:18 -, hjl dot tools at gmail dot com
<[EMAIL PROTECTED]> wrote:
>  Where is this documented in ISO C?

There is a Defect Report explicitly about this:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_236.htm

-- Pinski


-- 


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

[Bug c++/35024] [4.3 regression] ICE with parameter pack in nested type

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-30 10:08:22 |2008-02-14 21:43:43
   date||


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

[Bug c++/35025] [4.3 regression] ICE with invalid specialization of variadic template

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-30 10:07:52 |2008-02-14 21:44:56
   date||


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

[Bug ada/35194] floating point truncation error on intel platform

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-02-14 21:47 ---
Does the oracle library by any chance mess with the floating point precision
registers of the CPU?


-- 


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

[Bug c/35198] [4.1/4.2/4.3 Regression] missed evaluation of VM array type when used as a cast

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-14 21:42 ---
Confirmed.

This used to work with gcc 2.95 at least.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||3.3.6 4.1.3 4.3.0
  Known to work||2.95.4
   Last reconfirmed|-00-00 00:00:00 |2008-02-14 21:42:39
   date||
Summary|missed evaluation of VM |[4.1/4.2/4.3 Regression]
   |array type when used as a   |missed evaluation of VM
   |cast|array type when used as a
   ||cast
   Target Milestone|--- |4.2.4


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

[Bug preprocessor/35061] #pragma pop_macro causes ICE if no macro value on stack

[dannysmith at users dot sourceforge dot net]

--- Comment #3 from dannysmith at users dot sourceforge dot net  2008-02-14 
21:44 ---
Fixed


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug c++/35023] [4.3 regression] ICE with parameter pack in variable declaration

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-30 10:09:07 |2008-02-14 21:42:20
   date||


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

[Bug preprocessor/35061] #pragma pop_macro causes ICE if no macro value on stack

[dannysmith at gcc dot gnu dot org]

--- Comment #2 from dannysmith at gcc dot gnu dot org  2008-02-14 21:42 
---
Subject: Bug 35061

Author: dannysmith
Date: Thu Feb 14 21:41:40 2008
New Revision: 132322

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132322
Log:
PR preprocessor/35061
gcc
* c-pragma.c (handle_pragma_pop_macro): Check that
pushed_macro_table has been allocated.
testsuite
* gcc.dg/cpp/pragma_pop_macro-1.c:  New file




Added:
trunk/gcc/testsuite/gcc.dg/cpp/pragma-pop_macro-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-pragma.c
trunk/gcc/testsuite/ChangeLog


-- 


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